yzeng25 commented on code in PR #1745: URL: https://github.com/apache/apisix-website/pull/1745#discussion_r1439178510
########## blog/zh/blog/2023/12/15/high-availability-of-apisix-and-api7.md: ########## @@ -0,0 +1,163 @@ +--- +title: "借力 APISIX 的高可用，实现企业亿级流量" +authors: + - name: 王院生 + title: Author + url: https://github.com/membphis + image_url: https://github.com/membphis.png + - name: Yilia Lin + title: Technical Writer + url: https://github.com/Yilialinn + image_url: https://github.com/Yilialinn.png +keywords: + - 开源社区 + - API 网关 + - Apache APISIX + - 支流科技 + - API7 +description: +tags: [Case Studies] +image: +--- + +> 作者：王院生，支流科技联合创始人兼 CTO，Apache APISIX PMC 成员，《Apache APISIX 实战》作者。本文整理自 2023 年 11 月王院生在 APISIX 上海 Meetup 的演讲。 +<!--truncate--> + +## 支流科技简介 + +支流科技是一家成立于 2019 年的 API 全生命周期管理公司，致力于提供全面高效的 API 设计、API 开发、API 门户、API 货币化解决方案，服务对象包括 Zoom、爱奇艺、WPS、vivo、OPPO、Airwallex 等众多全球客户。我们曾开源并向 Apache 软件基金会捐赠了 API 网关 APISIX，如今 Apache APISIX 成为了 GitHub 上最活跃的 API 网关项目之一。目前，APISIX 每天处理超过 1 万亿次 API 调用，深受世界各国各行业的用户信赖。 + +在 Apache APISIX 基础之上，支流科技提供 API7 企业版及 API7 门户等企业级产品，满足企业用户的核心需求，包括多集群管理、多工作分区、权限管理、版本管理、审计、统计报表等企业级功能。支流科技在亚太地区 API 管理市场排名第一，被评为 2022 年 Gartner API 网关市场指南代表供应商，并荣获了 2022 年红鲱鱼全球百强奖项。 + +## 为什么高可用对企业 API 如此重要 + +首先，让我们探讨 API 的重要性。简而言之，在数字世界中，API 实际上扮演着交通工具的角色。就像在现实生活中，如果没有车辆、道路、轮船和飞机，我们将无法正常生活。而 API 实际上就是数字世界的交通工具，其重要性不言而喻。 + + + +### API 管理核心“三高” + +在了解了 API 的重要性之后，再依据重要性排序来了解 API 管理的核心“三高”，即高安全性、高可用性和高性能。 + +- **高安全**：安全性是 API 网关产品最重要的基本要求之一。如果一款 API 网关产品在安全方面存在问题，那么无论它在其他方面表现得多么出色，用户也无法选择它。安全性不仅依赖于产品本身，也与其周边生态息息相关。例如，爱奇艺将 DPDK 作为四层代理，但是基本上没有企业将 DPDK 用作 API 网关，正是因为其相关的基础设施周边生态系统太不完善，让用户缺乏安全感。 + +- **高可用**：高可用性是指几乎可以随时访问 IT 系统并保持可靠性，从而可以更大限度地消除或减少停机时间。关于高可用性，只要我们遵循相应的软件工程或者解决方案标准就可以实现，而能够实现高可用的产品往往能够达到令人称赞的水平。 + +- **高性能**：与前两个因素相比，高性能并非影响用户选择的关键因素，而是一个额外加分项。如果产品的性能表现优秀，用户自然会选择它；但如果 API 网关产品在高安全和高可用两个方面表现出色，即使的性能不佳，用户也可以接受。 + + + +### API 网关的重要性：内外网间的隔离屏障 + +API 网关位于内外网之间，它充当了内部和外部网络之间的隔离屏障。上图中 API 网关所处的位置涉及各种设备，包括人员、机器和车辆等正常设备；然而，这个位置也存在着那些从事黑客活动以谋取私利的个人或组织，它们可能占据不到万分之一的流量。而 API 网关的任务就是进行流量清洗，即从这万分之一甚至亿分之一的流量中识别并拦截这些恶意请求。 + +#### 私网安全威胁甚于公网 + +中外在安全拦截的认知方面存在明显差异。在中国，企业非常注重内网的隔离性和外网的安全性，例如专网、专线和私有网络，很多企业认为只要在内部私有网络中，不接触公网，就是安全的。 + +然而情况恰恰相反：私有局域网的安全性威胁往往比公网病毒更严重。因为在私网内，病毒在内部默认是被信任的，完全不会被拦截，一旦病毒能够进入私网任何一个节点，就可以在内部网络自由传播，后果不堪设想。 + +在 2006 年，我亲身经历了“熊猫烧香”事件，也遇到过公司利用局域网的传播能力自动分发 Windows 病毒文件的情况。现在许多企业的安全能力相对较弱，甚至大多数企业采用了一种“裸奔”的方式，即内部服务直接调用的方式，通过 HTTP 进行访问，缺乏身份认证、访问权限控制或限流限速等措施，这是安全能力弱的企业可以着手优化的方面。 + +#### WAF 产品逃生机制的重要性 + +流量网关所处的位置通常涵盖三个主要产品线：DDoS 流量清洗、Web 应用防火墙（WAF）和 API 安全解决方案。在网关所处的这个位置，需要进行流量清洗。只要请求能够通过这道屏障，我们就认为该请求是可信赖的，因而一个关键点是要增加适当的逃生机制。 + +举个例子，DataVisor 对延迟极为敏感，限制服务延迟在 50 毫秒以内。超过此阈值，调用方将认为服务不可用，并继续执行其他操作。这实际上是一种可逃生的安全策略：安全系统在 50 毫秒内无响应则默认服务宕机，放行请求，继续执行下一步操作。 + +在流量管理中，云产品的 WAF 都应该具备可逃生能力。许多企业在使用云产品的 WAF 时都遇到过问题，因为 WAF 有可能因为某一套规则而导致自身的 CPU 超负荷而崩溃，这种紧急情况下它应该具备逃生能力，保证系统的可用性和安全性。 + +### 高可用指标及常见 API 网关部署架构 + +主流部署架构 + +常见的 API 网关部署架构有四种：私有云、多云、混合云和单朵云。其中单朵云只占不到 5%，而剩余 95% 的企业都选择前三种部署方式。单朵云的部署架构是由单一云服务提供商提供的部署架构，用户只需使用云服务提供商的默认设置，就可以在自己的环境中运行。因此，用户无需过多关注架构的细节，甚至可以将重点放在服务开发上。 + +而私有云、多云、混合云这三种架构类型在全球企业中占据了主导地位。这些主流解决方案，无论是微服务架构还是网关架构中都被广泛接受。然而，在这些方案中有一个很重要但常常被忽视的因素，那就是用户需求。与用户群体进行有效的沟通和需求分析是一个加分项，让用户了解并认同产品或服务，这才是关键。 + +#### API 网关要求：云中立、允许二次扩展、“三高” + +云中立指的是软件具备在不同的云平台上运行的能力，甚至可以在各种虚拟机上运行，也可以称之为全平台运行。网关支持二次开发是一个重要因素，这也是诸多企业选择 APISIX 的一个重要因素。另外，高安全性、稳定性和可用性是非常重要的指标。 + + + +上图展示了不同的高可用性指标及其出现故障的时间。可用性为“99%” 的情况下，每天可以有 14 分钟的停机时间。即使出现问题，研发人员可以快速处理，无需加班。“99.9999%” 这种情况比较少见，因为越高的可用性意味着企业需要承担越昂贵的部署成本。所以我们主要讨论的是“99.9%”、“99.99%”、“99.999%”这几种可用性的情况。 + +#### 无状态服务横向扩展系统能力 + +在讨论高可用之前，先谈谈有状态和无状态的服务。有状态和无状态的区别在于，有状态的服务具有很强的不可替代性，反之亦然。例如，你必须使用某个服务，否则无法正常工作，那么该服务就是有状态的；假设这个服务本身没有任何缓存，只是用于处理逻辑，如接收一个 API 请求，然后查询数据库，得到结果后返回，那么该服务就是无状态的。 + +通过在服务中引入有状态的组件，会导致服务失去无状态的特性，因为这些组件需要进行主从同步和恢复。这会给服务的可扩展性带来限制。所以，在设计服务时，要尽量避免使用有状态的组件。SLB（负载均衡）始终被认为是无状态的，它可以在一次规则匹配后正常工作，而不依赖其他条件。只要 SLB 启动并且网络通畅，它就能直接工作。因此，这一点非常重要，企业应该尽量消除服务中所有有状态的元素。 + +在复杂的企业体系中，真正优秀的公司是所有服务都是无状态的，因为无状态的服务可以无限横向扩展。因此，请放心将所有状态存储在类似于服务发现或关系型数据库（如 RDS）这样的组件中，而不是存储在某些服务中，从而确保有状态服务的数量越少越好。通过这种方式，可以将所有应用服务按需横向扩展，系统的能力也将变得无穷无尽。 + +#### 常见高可用部署架构 + +在互联网行业中，涉及支付的应用通常采用“99.9%”或“99.99%”的可用性水平。例如我们日常使用的一些常见应用，如视频观看、消息查看和评论等。 + +部署“99.9%”的可用性相对简单，只需要建立好主从数据库的架构，确保数据库之间有一个良好的主备关系，甚至可以使用单个云服务器或单个可用区。一旦发现主数据库出现问题，可以切换到备用数据库，并进行 IP 漂移。这个过程可以自动化，即使不通过自动化的形式，在出现故障时也有足够的时间进行人工干预处理。 + +这种部署方式成本较低且相对简单。如果应用程序部署在某个云服务商的单个机房中，只要这个机房没有问题，那么可以认为它的可用性可能高于“99.9%”，近乎 100%。在这种情况下，主要的风险点在于数据库的可用性。 + +“99.9%”和“99.99%”之间唯一的区别在于“99.9%”是单机房，而“99.99%”是双机房，并且机房之间可以交叉访问。 + + + +下图描述的是高可用性为“99.999%”的“两地三中心”部署架构。图中展示的左侧是华东，右侧是华南，总共有三个中心，分别是可用区 A、B 和 C。图中的 LB、外部服务和应用服务都没有状态，只有 RDS Master 是有状态的。这种架构要求数据库实现三主多活。左侧的服务可以通过在负载均衡器（LB）、网关和服务层之间进行交叉调度，实现不同中心之间的负载均衡。只有应用程序符合无状态的要求，才能轻松地实现高可用性。 + + + +更多内容可查看文章：http://kaito-kidd.com/2021/10/15/what-is-the-multi-site-high-availability-design/。 + +## 高可用架构认知盲区 + +### 高可用架构，从计算机诞生起一直在迭代 + +高可用架构并非是最近才出现的，实际上，从计算机诞生的那一天起，它就已经存在了。在没有 DNS 的时代是直接通过 IP 进行访问的。后来人们意识到必须解决单点问题，即一台机器发生故障后需要有应对措施，以免整个互联网崩溃。因此，在设计互联网时，人们逐步引入了一些解决方案，DNS 就是其中之一。但是，DNS 本身并没有逃生机制，一旦 DNS 被禁用，将会导致互联网瘫痪。 + +高可用架构的出现是为了满足各种各样的企业目标和平台目标。我们必须实现自己的职责，不仅为了满足老板的要求，也为满足整个公司的要求。高可用在业务本质上没有为系统增添任何新功能，它只是为了确保投资回报的可能性。但无论是最早的传统单一大应用还是现在，高可用一直都是标配，只是实现方式略有差异。 + +以前要实现高可用性，意味着需要购买昂贵的小型机器或专用的 ECG（Enterprise Cloud Gateway），比如 EMC 的 Earco，成本太高。谷歌在早期就发现了这一点，他们通过统一管理廉价的个人电脑，最终实现了专用硬件的效果。然而，从现代的角度来看，随着微服务和 Kubernetes 容器编排的技术为人们所接受，在理解了其内部原理之后，我们每个人都有能力去颠覆当年存储硬件的方案。 + +### 高可用架构，只能解决架构部分 + +高可用提供的只是架构方面的解决方案，它对源代码和业务质量也有要求，并且单纯依靠高可用方案提升整个系统可用性是不切实际的。架构之外的问题仍然需要我们去解决，比如 WAF 和 DDoS，比如配套的应用，以及网关本身在不遇到硬件问题情况下，必须保障其本身达到“99.99%”或“99.999%”单机运行的能力。 +我们所提到的这些并非真理，而是方法论上的兜底。 + +### 高可用与安全一样，均是全方位立体“防护” + +安全性不仅仅是 API 网关的问题，我们不能只看单个点，而应该从整个 API 体系的角度，全面考虑与 API 网关相关的因素。我们首先要关注自身，然后再考虑外部因素。从内部而言，我们可以考虑以下几个方面： + +- 通过软件工程规范，拉高质量下限：先确保自身的高可用与安全，必须通过软件工程的方法，提升自身服务及其相关服务的质量；再认真进行测试和灰度；我们还应建立完善的流程，确保不会有任何绕过流程的情况发生。 + +- 如果是非必要流程，考虑建立逃生机制：WAF 和 DDoS 都是可插拔的，我们可以根据需求加入或移除它们。 + +对于外部服务，我们必须特别注意我们所依赖的周边环境，确保它们没有潜在的问题。 + +- 依赖服务均需支持高可用，比如 LB、DNS 服务等：我们务必对依赖服务进行排查，比如负载均衡（LB）和域名系统（DNS）。特别是对于 DNS，我们需要提供备用选项。举个例子，在上课或上网时，路由器会连接到互联网，其中包括宽带接入，而路由器默认至少具有两个 DNS 地址，第一个 DNS 地址设置为主要，第二个 DNS 地址作为备用。由此一来，如果主要的 DNS 无法正常工作，可以自动切换到备用 DNS。 + +- 变量因子需支持回滚机制，比如服务发现等：从外部的角度看，变量因子可能会提供一些输入，然而其中可能存在非法的情况，导致异常情况的发生。这种情况常常发生在服务发现中，以及管理员添加策略时。所以，在处理变量因子时，我们需要注意内外部的因素，并确保在内部实现中进行验证和回滚操作，以保障系统的稳定性和安全性。开源的 APISIX 和 Dashboard 上，默认情况下没有回滚按钮，但 etcd 本身具备回滚能力，可以查看其文档或策略机制以了解更多细节；API7 企业版对此提供了针对性的功能，在快速定位到问题位置后，则只需在界面上点击相应的副本按钮即可实现回滚，甚至可以使用手机进行操作。 + +## APISIX 与 API7 企业版高可用最佳实践 + +开源版和企业版是两种不同的解决方案，它们在最佳实践上有一些区别。在开源方案中，我们考虑了基本的高可用性理念。不论是使用 Dashboard 还是开源的 API 网关，都可以实现高可用性。开源方案的设计初衷是尽量保持无状态，以便进行横向扩展、缩容和高可用性的调整。例如，如果某个组件发生故障，不会影响整个系统的运行，可以通过部署多个副本来提高可用性。根据需求可以部署任意数量的副本，没有限制。 + +### 开源方案 APISIX + +开源方案的早期版本可能存在一些错误和崩溃，但这并没有影响其发展。而正是因为 APISIX 是无状态的，它支持高可用性，允许部分业务挂起，因而部分业务的故障不会对整个系统造成影响。在 APISIX 中实现高可用性时，只需专注于实现 etcd 的高可用性，要想实现 etcd 的高可用性，可以先研究 Kubernetes 的高可用性。 + + + +### 商业方案 API7 企业版 + +为了满足国家信创的要求，并兼顾商业公司的成本和风险，API7 企业版将 etcd 替换为了 PostgreSQL 的数据库解决方案。同时为了保持与开源方案的兼容性，API7 企业版仍然使用 etcd 的通信协议，它通过引入一个新的服务，将数据库中的配置翻译成 etcd 的通信协议，从而完成配置的分发。 + +![]() Review Comment: missing an image here -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
