中文Microservices June 微服务之月 2023 现已开放注册。点击此处，查看议程并注册参加。
微服务是一种使用多个小组件构建复杂应用的方法。本文介绍了它的工作原理、优缺点及其可带来的优势。
什么是微服务？
微服务是一种利用多个小组件（每个组件执行一种功能，例如身份验证、通知或支付处理）构建大型复杂应用的软件架构方法。每个微服务都是软件开发项目中的一个独立单元，具有自己的代码库、基础设施和数据库。微服务协同工作，通过 Web API 或消息队列进行通信，以对传入事件作出响应。
关于微服务的视频
为何采用微服务架构？
在传统单体架构中，一个应用的所有功能均在单个代码库中实现。这种方法有几个弊端：
- 随着应用日趋复杂，任何一位开发人员都很难弄清整个代码库。新入职的开发人员也很难上手。一个解决办法是将不同的功能模块分配给不同的开发人员或团队。这样开发人员可以更轻松地掌控自己的代码，但问题是会更难跟踪与其他模块的依赖关系。因此，一个模块的变更很有可能会影响其他模块。
- 当您需要添加或增强功能时，您必须编译并测试整个应用，以验证该变更是否会破坏模块之间的兼容性。然后，您必须将整个应用作为单个二进制文件进行部署。
而微服务架构则将应用功能划分成多个独立的微型服务（service），有助于简化 CI/CD。微服务开发速度更快且更易于理解和维护。每个服务均可由只专注于该服务的团队独立开发。该团队可以选择最适合微服务的编程语言、开发平台和数据库。微服务通常封装为容器，以进一步简化部署。
微服务具有松散耦合性，这意味着它们不依赖于其他微服务的内部构件。它们之间通过 API 进行通信。只要每个微服务暴露的 API 保持向后兼容，对一个微服务进行更改时，便无需更新其他任何微服务。
简而言之，想要在微服务架构中进行修改的开发人员可以在单个微服务容器中执行这一操作，而在单体架构中操作的开发人员则可能不得不耗费大量的时间来重写整个堆栈。
微服务使用群体
为了快速响应不断变化的业务需求，技术团队纷纷转而采用微服务架构。开发人员正引领这一变革，这在很大程度上是因为更多企业授予了开发人员选择应用和交付工具的权限。2020 年开展的一项 NGINX 用户调查显示，超过一半的受访者在其部分或全部应用中使用微服务。 2022 年，在正弃用单体系统的公司工作的更多 NGINX 用户表示，之所以采用微服务，在一定程度上是因为容器编排所允许的可扩展性。
微服务 101：优缺点
微服务可将传统的单体应用转变为更加灵活、安全且高效的架构，从而帮助您节省大量时间、成本和资源。下面总结了微服务的优缺点，这些优缺点可能影响应用性能和设计。
- 开发人员可以自由地独立开发和部署服务，从而提高决策速度。
- 得益于微服务的小规模和自主性，基于微服务的方法能够缩短开发周期，因为不同的团队可以同时实现不同的服务。团队之间的依赖性通常会减弱甚至消除。
- 微服务可轻松地部署至容器，有助于减少开销并提高跨不同环境的可移植性。
- 由于微服务很容易与 CI/CD 工具集成，因此开发人员可实施现代 DevOps 实践，例如自动化 CI/CD 流水线。
- 轻松扩展应用，按需“调整大小”，因为通常每个服务都弹性十足。
- 微服务更易于构建、测试和维护。
- 服务围绕业务功能组织实施。
- 开发人员可以采用最适合特定服务的技术。
- 更轻松地隔离故障——如果一个微服务发生故障，其他微服务仍可继续运行。
- 微服务架构会加剧复杂性，因为开发人员必须降低容错率，缩短网络延迟，处理不同的编程语言，并跨多个服务实现负载均衡。
- 由于微服务具有分布式特性，因此微服务故障排除可能繁琐复杂。
- 增加应用中的微服务数量会增加集成和管理工作。
- 处理多个数据库可能相当困难。
API 是微服务吗？
简而言之，不是。API 本身不是微服务。但 API 正越来越多地作为应用内的通信机制集成到微服务架构中。一个微服务的功能暴露为一组 API 端点，其他微服务通过对相应端点进行 API 调用来调用该功能。
为何使用容器来运行微服务？
容器化平台支持开发人员以不受基础设施限制的最高效方式隔离、扩展并部署微服务，同时最大限度地减少对用户的干扰。设想这样一种情景：在您的应用前面部署单个负载均衡和流量路由服务器集群。借助在 DNS 中发布的静态公共 IP 地址，客户端可将其请求发送到这个稳定的入口点，然后该请求会被转发到相应的容器。如果添加或删除这些容器，只需更新内部地址即可将这些请求定向到新的 IP 地址。您也可以通过 DNS 在内部发布这些地址。
微服务案例
微服务加速了受严格管制行业中的无缝安全迁移
一家身处受严格监管行业的跨国公司必须按照规定的时间表升级其系统，以确保遵守不断演进的标准和最佳实践。这家公司的应用组合每天通过其系统处理数百万笔交易。多年来，即使在开源升级和第三方安全插件集成期间，该公司仍然遵守行业要求。然而，在最近的一次升级中，由于插件互斥问题，该公司遇到了一些难题。该公司曾考虑从数据中心迁移到 AWS 公有云，但安全插件问题促使其迁移到了微服务架构。这种解决方案的成本更低，并可帮助该公司快速实现安全合规。
请阅读此客户成功案例，了解有关微服务迁移的更多信息。
博文
成功案例和用例
- Tipico 依靠 NGINX Plus 迁移至微服务并在云端提供可靠性能
- SISTIC 借助 NGINX PLUS 降低八成成本，加快上市速度
- Team Fresh 利用 F5 NGINX Plus 优化微服务和云环境
- Canal+ 从 NGINX 开源版升级到 NGINX Plus 以支持其迁移至微服务
- EPAM 使用 NGINX Plus 早于全球其他公司五年构建 Windows 容器
参考资料
