微服务开篇-微服务架构

微服务介绍

微服务架构是一种流行的架构设计风格，通常用作单体（Monolith）架构的一种替代方案。

目前，我们开发的大部分应用都是单体应用。当单体应用的复杂度增加时，会出现一系列的问题。微服务架构吸引人的地方在于它对复杂应用的开发提供了一种新的解决方法。微服务架构的核心思想是把应用按照功能划分成多个独立的服务，每个服务都是独立运行的应用。

如下图所示，外部的边框是应用的边界，不同的形状表示不同的单元。图中左侧表示的是单体应用，所有单元在同一个应用的边界内。在进行扩展时，单体应用只能整体扩展；右侧表示的是微服务架构的应用，每个单元在自己的应用边界内。在进行扩展时，微服务架构的应用以服务为单位进行扩展。不同服务在运行时的实例数量可以根据负载动态进行调整。

在介绍微服务架构之前，有必要先看一下单体应用存在的问题，从而了解微服务架构要解决的问题。

单体应用的问题

初学 Java，我们就知道 main() 方法的作用，以及如何使用 Java 虚拟机来运行一个应用。这样的应用就是单体应用。单体应用是我们最熟悉的开发应用方式，从开发、测试、部署到维护的全过程，积累了很多经验。但是当单体应用不断更新升级和扩充功能时，一些问题就会出现。

第 1 个问题是单体应用过于复杂，超出了单个开发人员的理解能力。

虽然可以通过组件化把单体应用划分成多个单元，降低每个单元的复杂度，但在实际开发中，组件化的效果并不是很好。一方面是因为公共代码的存在，这些共享的代码由于被多个组件使用，难以高效更新；另一方面由于文档缺失和开发过程中的各种不规范行为，造成组件之间的接口不清晰。在 Java 代码中，我们可以很容易地调用其他组件中的接口和类的方法，从而在不同组件之间有意或无意的引入依赖。所产生的结果就是单体应用中不同组件之间的依赖关系非常复杂。 

第 2 个问题是缓慢的开发速度。

当应用变得复杂时，开发人员则需要花费更多的时间来理解所做的改动对已有代码的潜在影响。经常遇到的情况有，一个看似很小的改动，会对应用造成很大的影响。当这样的情况出现多次之后，开发人员由于怕承担责任，变得不情愿改进代码的质量，同时，在本地开发环境上进行开发和调试变得更加耗时。在 IDE 中修改代码之后，编译和重启应用的时间过长，本地单元测试也需要更长的时间来运行。所产生的结果就是开发人员的宝贵时间耗费在无意义的等待上。

第 3 个问题是应用的扩展变得很困难。

当应用的处理能力不能满足业务需求时，需要进行扩展，扩展分为垂直扩展和水平扩展两种。垂直扩展的做法是增加单个应用实例所能使用的资源，这导致的问题是不同组件对资源需求的冲突，有些组件对内存的消耗较大，而另外一些组件对 CPU 的要求高，当无法同时满足两者时，则需要作出取舍。水平扩展的做法是增加应用的实例数量，水平扩展只能以应用为单位来进行，如前面的图片所示，应用中不同组件的负载程度是不同的，以电子商务应用为例，商品展示和订单处理相关组件的负载要大于客户服务相关的组件，以应用为单元的扩展方式无法有效的分配资源。

第 4 个问题是新版本更新上线的速度变慢。

现在的应用都要求能够及时响应用户的需求，以最快的速度添加新功能和修复问题，这意味着一天可能要进行很多次的产品更新。单体应用由于复杂度高，每一次代码提交之后的持续集成所花费的时间过长。由于需要运行全部的测试用例，限制了更新的频率。

第 5 个问题是整个应用的稳定性变差。

由于整个应用只有一个进程，组件之间缺少必要的隔离性，任何一个组件中出现的问题，比如内存泄漏，都会导致整个应用的崩溃。当某个组件占用大量的 CPU 和内存资源时，会导致其他组件由于资源不足而无法正常工作。

第 6 个问题是技术栈的选型和更新变得困难。

单体应用通常只使用单一的技术栈，包括编程语言、所用框架、第三方库，以及数据库和消息中间件等，这就要求所有的开发人员都掌握相同的技术栈，事实上，不同组件由于需求的不同，有它最适合的技术栈。强制使用单一技术栈，无疑会对开发效率产生影响，一旦技术栈选型确定之后，要对它进行更新是一件非常困难的事情，整个应用都可能受到影响。所产生的效果就是应用的技术栈不断的老化，带来更多的问题，形成恶性循环。

微服务架构的特征

对于微服务架构，并没有一种统一的定义，不同的人有不同的表达形式。Martin Fowler 是这样表述的：微服务架构风格把应用划分成若干个服务，每个服务有自己独立的进程，服务之间通过轻量级传输机制进行交互。这个表述包含了微服务架构的一些重要特征。事实上，我们关注更多的并不是微服务架构的定义，而是它所具备的特征，这些特征可以帮助我们确定是否应该选用微服务架构。

微服务架构使用服务作为组件化的单元。组件化是软件开发中的基本实践，在 Java 应用开发中，组件通常以 JAR 文件的形式出现，Maven 仓库中包含了海量的第三方库可供使用，Java 开发人员都熟悉这种使用组件的方式。在微服务架构中，组件的单元变成了服务，服务运行在独立的进程中，不能通过直接的方法调用来访问，而需要使用类似 HTTP 这样的进程间通信方式，每个服务可以独立部署，使用 API 规范来描述其公开接口。一个微服务只能通过 API 访问另外的微服务，并不能访问内部的实现代码。

如下图所示，不同服务之间存在调用关系，调用的方式可以是 REST 或 gRPC。

 

微服务架构的开发团队围绕业务能力来组织。单体应用的开发团队通常按照技能来划分，一个典型的 3 层应用开发团队可能分成前端开发、后端开发和数据库管理等小组。微服务架构的开发团队以服务为单元来组织，每个服务与特定的业务需求相对应。服务的开发团队规模较小，包含开发、测试和 DevOps 相关的全部人员，负责该微服务的团队对该微服务的实现可以全权负责。较小的开发团队意味着更少的沟通成本和更高的开发效率。

微服务架构使用去中心化的管理模式。单体应用的开发团队通常会对使用的技术栈做出限制，要求整个团队使用统一的技术栈。这种方式的弊端在于，没有一种技术栈适用于解决所有的问题。微服务架构中的服务都可以独立部署，这就意味着每个服务在实现时可以选择最适合的技术栈，只需要满足服务的 API 契约即可。每个团队自主管理所负责的服务，不但负责构建，还同样负责运行和维护，这在无形中提高了团队的主观能动性，同时降低了管理的开销。

如下图所示，每个微服务都有对应的团队，而每个团队中都有各种角色的人员。

 

微服务架构使用去中心的数据存储。单体应用通常使用单一数据库来存储数据，微服务架构中的服务通常有自己专有的数据存储，如下图所示。这些存储方式的实现可能各不相同，只包含服务所需的数据。 

 

微服务架构强调基础设施的自动化。持续集成和持续部署都是通用的实践，单体应用由于只有一个部署单元，对自动化的要求并不高。微服务架构中的服务可以独立部署，但当服务的数量较多时，必须通过自动化的流程来完成。

微服务架构在设计时充分考虑到失败的情况。这是因为服务之间通过进程间通讯方式进行交互，这样的交互方式天生就容易失败，调用时的目标服务可能失败或负载过大。

微服务架构的实现

微服务架构所涵盖的内容非常广泛，对不同角色的人员，其意义并不相同：

• 从架构的角度来说，它是由多个独立服务组成的分布式系统；
• 从人员管理的角度来说，它要求员工组成小而完备的自主团队；
• 从项目管理的角度来说，它推荐使用敏捷软件开发流程，如 Scrum 或 Kanban；
• 从开发的角度来说，每个服务有独立的业务逻辑实现和数据存储，使用开放 API 作为边界；
• 从测试的角度来说，需要对服务的 API 契约进行测试；
• 从运维的角度来说，持续集成和持续部署对微服务架构的成功至关重要。

微服务架构的实践是一项系统化的工程，需要很多人的协同合作。作为开发人员，我们更多关注的是如何完成服务的实现，但除了每个服务本身的实现之外，还包括与其他服务的协作。

从实现的角度来说，我们需要考虑表中的这些因素。

 

表中列出的关于服务实现的相关内容，在大部分微服务架构的应用中都会出现。但在实际的项目开发中，你并不会从零开始实现所有相关的内容，而是使用已有的平台、框架和技术，流行的技术选择包括 Netflix OSS 栈、Spring Cloud 和 Kubernetes 等。   

Netflix 是微服务架构实践中的引领者，不仅在生产系统中成功应用了微服务架构，还把相关的库和工具以开放源代码的形式共享出来，形成了 Netflix OSS 栈。

Spring Cloud 是由多个开源项目组成的开发套件，用来实现分布式系统中的常见模式，如配置管理、服务发现和断路器等，可以用来实现微服务架构的应用。它的优势在于提供了一个抽象框架，可以避免供应商锁定的问题，对于同一个模式，它可以切换底层的实现方式。Spring Cloud 本身是基于 Spring 框架的，对于一直工作在 Spring 框架上的团队来说，Spring Cloud 是一个不错的选择。

Kubernetes 是管理容器化工作负载和服务的平台，同时也是容器编排平台，微服务及其依赖的其他服务通常以容器的形式运行。Kubernetes 对表中的很多需求都提供了原生的解决方案，对于另外的一些需求则有开源实现，是运行微服务架构应用的良好平台。