关于微服务的理解

关于微服务的理解

1.为什么要采用微服务&微服务核心思想

1.1单体架构如何保证高可用

单体架构在应对高并发访问的时候，通常是采用负载均衡器运行许多实例来水平扩展单体，也就是通过集群的方式来保证系统的高可用性。

1.2单体水平扩展（集群）的缺点

通过水平扩展单体来达到高可用目的的最大问题在于，当我们对应用程序中的某一处进行修改时，需要将整个单体进行重新构建和部署。

1.3正是单体架构存在的这些问题才催生了微服务架构风格。

1.4微服务的核心思想

微服务采用去中心化的思想，将应用程序构建为服务套件，每个服务可以独立部署和扩展，每个服务与其他服务有清晰的边界，允许不同服务采用不同的编程语言，服务由不同的团队进行管理。

1.5康威定律

任何设计系统（定义广泛）的组织都将产生其结构是组织通信结构副本的设计。
——梅尔文·康威，1968.
图示：引用自：微服务James Lewis&Martin Fowler

根据康威定律，我们可以知道原理上，产品的架构和团队的通信架构应该是一致的。因此在采用微服务的公司中，每个团队有自己独立的前端、后端、数据库管理员、测试以及运营。根据亚马逊提出的“谁创建，谁运行”的思想，每个服务所属团队会对该服务的整个生命周期进行负责。
注：“跨职能团队（cross-functional teams）是指把各种工作领域具有不同知识、技能的员工组合起来识别和解决共同的问题的团队。
注：一个团队可以负责多个服务，但原则上一个服务只对应一个团队。
图示：引用自：微服务James Lewis&Martin Fowler

1.6为什么是构建为服务，而不是库？

使用服务作为组件（而不是库）的一个主要原因是服务是可独立部署的。如果您的应用程序在单个进程中包含多个库，则对任何单个组件的更改都会导致必须重新部署整个应用程序。但是，如果该应用程序被分解为多个服务，您可以预期许多单个服务更改只需要重新部署该服务。

1.7构建为服务的优点

使用服务作为组件的另一个结果是更明确的组件接口。大多数语言没有定义显式发布接口的良好机制。通常只有文档和规范才能防止客户端破坏组件的封装，从而导致组件之间的耦合过紧。服务通过使用显式远程调用机制更容易避免这种情况。

1.8构建为服务的缺点

使用这样的服务确实有缺点，在通信方面，远程调用比进程内调用代价更高，因此远程 API 需要更粗粒度。

1.9服务边界

图示：引用自：微服务James Lewis&Martin Fowler

如图不同的业务团队之间有明显的边界、对应的服务之间也有明显的边界。以这种方式组织的一家公司：该公司是国外公司，需要科学上网。

2.0跨职能团队负责构建和运营每个产品，每个产品都被拆分为多个通过消息总线进行通信的单独服务。

注：跨职能团队：“跨职能团队（cross-functional teams）是指把各种工作领域具有不同知识、技能的员工组合起来识别和解决共同的问题的团队。

2.1最常用的两种协议是带有资源 API 的 HTTP 请求-响应和轻量级消息传递。

2.2去中心化治理

也许去中心化治理的最高点是亚马逊推广的构建 / 运行它的精神。团队负责他们构建的软件的所有方面，包括24*7 全天候运行软件。这种级别的责任下放绝对不是常态，但我们确实看到越来越多的公司将责任推给开发团队。Netflix 是另一个采用这种精神的组织。每天凌晨 3点被寻呼机叫醒无疑是在编写代码时关注质量的强大动力。这些想法与传统的集中式治理模式相距甚远。

2.3去中心化数据管理

除了分散有关概念模型的决策外，微服务还分散了数据存储决策。单体应用程序喜欢使用单个逻辑数据库来存储持久数据，微服务更喜欢让每个服务管理自己的数据库，可以是相同数据库技术的不同实例，也可以是完全不同的数据库系统。
图示：引用自：微服务James Lewis&Martin Fowler

2.4数据一致性问题

众所周知，分布式事务难以实现，因此微服务架构强调服务之间的无事务协调 ，明确认识到一致性可能只是最终的一致性，问题通过补偿操作来处理。企业通常会处理一定程度的不一致以快速响应需求，同时有某种逆转过程来处理错误。只要修复错误的成本低于在更高一致性下失去业务的成本，这种权衡是值得的。

2.5基础设施自动化

基础设施自动化技术在过去几年中发生了巨大的发展—云的发展，尤其是 AWS，降低了构建、部署和运营微服务的运营复杂性。许多使用微服务构建的产品或系统是由具有丰富持续交付经验的团队构建的，它的前身是持续集成 。以这种方式构建软件的团队会广泛使用基础设施自动化技术。这在下面显示的构建管道中进行了说明。
注：AWS即Amazon Web Services，是亚马逊（Amazon）公司旗下的全球最全面、应用最广泛的云平台。 从全球数据中心提供超过 200 项功能齐全的服务。数百万客户(包括增长最快速的初创公司、最大型企业和主要的政府机构)都在使用 AWS 来降低成本、提高敏捷性并加速创新。
注：持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

2.6单体应用程序整体是一个进程，微服务中的每个服务都是一个独立的进程。

2.7面向失败设计

使用服务作为组件的一个结果是，应用程序需要被设计成能够容忍服务的失败。由于供应商不可用，任何服务调用都可能失败，客户必须尽可能优雅地对此做出响应。与单片设计相比，这是一个缺点，因为它引入了额外的复杂性来处理它。结果是微服务团队不断反思服务故障如何影响用户体验。Netflix 的Simian Army 在工作日期间会引发服务甚至数据中心的故障，以测试应用程序的弹性和监控。