微服务（microservices）

-微服务架构
微服务是一种分布式架构风格。它具有多种优点，例如：
. 可以提高可扩展性。
. 开发团队可以独立工作并变得更加敏捷。
. 服务的独立性提高了代码的可重用性。
. 系统的整体架构可以与组织结构保持一致。
但是，由於分布式架构的性质，微服务的可用性、可管理性和监控可能需要更多的开销。可扩展性和可用性的概念经常被混淆。可伸缩性是关於服务可以服务多少客户端，而可用性是客户端可以可靠和及时地访问服务的程度。
服务或系统可以采用不同的可扩展性策略，例如，纵向扩展或横向扩展。扩展策略可能不会提高可用性。横向扩展策略在不同程度上有助於提高可用性，例如，没有心跳检查的基於 DNS 的循环负载均衡器呈现的可用性程度低於检查服务健康状态的基於集群的负载均衡器。
以下是 NIST SP 800-204 的摘录：

微服务的优势
. 对於大型应用程序，将应用程序拆分为松散耦合的组件可以实现分配给每个组件的开发团队之间的独立性。然後，每个团队都可以通过选择自己的开发平台、工具、语言、中间件和硬件来优化，基於它们对正在开发的组件的适用性。
. 每个组件都可以独立缩放。资源的有针对性的分配导致资源的最大利用。
. 如果组件具有 HTTP RESTful 接口，只要接口保持不变，就可以在不中断应用程序整体功能的情况下更改实现。
. 每个组件中涉及的代码库相对较小，使开发团队能够更快地生成更新，并为应用程序提供响应业务流程或市场条件变化的敏捷性。
. 组件之间的松散耦合能够抑制微服务的中断，从而将影响限制在该服务上，而不会对其他组件或应用程序的其他部分产生多米诺骨牌效应。
. 当组件使用异步事件处理机制链接在一起时，组件中断的影响是暂时的，因为所需的功能将在组件再次开始运行时自动执行，从而保持业务流程的整体完整性。
. 通过将服务定义与业务能力对齐（或通过基於业务流程或能力的整体应用程序功能的分解逻辑），基於微服务的系统的整体架构与组织结构保持一致。当与组织单位相关的业务流程发生变化并因此需要修改和部署相关服务时，这促进了敏捷响应。
. 微服务的独立功能特性促进了跨应用程序的代码更好的可重用性。
. 必须监控多个组件（微服务）而不是单个应用程序。需要一个中央控制台来获取每个组件的状态和应用程序的整体状态。因此，必须创建具有分布式监控和集中查看功能的基础设施。
. 多个组件的存在会造成可用性问题，因为任何组件都可能随时停止运行。
. 一个组件可能必须为某些客户端调用另一个组件的最新版本，并为另一组客户端调用同一组件的先前版本（即版本管理）。
. 运行集成测试更加困难，因为需要一个测试环境，其中所有组件都必须工作并相互通信。
. 当基於微服务的应用程序内的交互设计为 API 调用时，必须实现安全 API 管理所需的所有必要流程。
. 微服务架构可以分解纵深防御的做法。许多架构都有一个运行在 DMZ 中的 Web 服务器，预计会受到威胁，然後是 Web 服务器与之通信的後端服务，最後是後端服务与之通信的数据库。後端服务可以充当暴露的 Web 服务器和数据库中的敏感数据之间更坚固的层。微服务架构往往会破坏这一点，现在 Web 服务器和後端服务被分解为微服务，可能比以前的模型暴露得更多。这会导致调用者和敏感数据之间的保护层更少。因此，安全地设计和实现微服务本身以及服务网格或API 网关部署模型。

参考
. NIST SP 800-204

资料来源： Wentz Wu QOTD-20210822
My Blog: https://choson.lifenet.com.tw/