为何微服务架构势在必行？

做者：成富，资深架构师，拥有多年一线开发经验，曾就任于IBM，后移居海外创业，现任公司首席软件工程师，负责基于微服务架构的云原生产品研发。资深技术做家，著有多部中英文技术书籍：《深刻理解 Java7 》《Exploring Java9》等。

*本文经做者受权整理发布，内容选自《云原生微服务架构实战精讲》

这两年，微服务做为一种架构方式，已经从论坛热词走向了真正的技术热点， 诸多大厂（好比 Amazon、Netflix、蚂蚁金服、网易云音乐等）已经迁移并采用了微服务架构。市面上微服务的图书、教程也层出不穷，为何互联网行业如此拥抱微服务？了解一下行业发展问题和微服务架构的优点，也就不难理解了。

目前，咱们开发的大部分应用都是单体应用。当单体应用的复杂度增长时，会出现一系列的问题。

单体应用的问题：

第 1 个问题是单体应用过于复杂，超出了单个开发人员的理解能力。虽然能够经过组件化把单体应用划分红多个单元，下降每一个单元的复杂度，但在实际开发中，组件化的效果并非很好。一方面是由于公共代码的存在，这些共享的代码因为被多个组件使用，难以高效更新；另外一方面因为文档缺失和开发过程当中的各类不规范行为，形成组件之间的接口不清晰。在 Java 代码中，咱们能够很容易地调用其余组件中的接口和类的方法，从而在不一样组件之间有意或无心的引入依赖。所产生的结果就是单体应用中不一样组件之间的依赖关系很是复杂。

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

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

第 4 个问题是新版本更新上线的速度变慢。如今的应用都要求可以及时响应用户的需求，以最快的速度添加新功能和修复问题，这意味着一天可能要进行不少次的产品更新。单体应用因为复杂度高，每一次代码提交以后的持续集成所花费的时间过长。因为须要运行所有的测试用例，限制了更新的频率。

第 5 个问题是整个应用的稳定性变差。因为整个应用只有一个进程，组件之间缺乏必要的隔离性，任何一个组件中出现的问题，好比内存泄漏，都会致使整个应用的崩溃。当某个组件占用大量的 CPU 和内存资源时，会致使其余组件因为资源不足而没法正常工做。

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

若是你的单体应用遇到了上述问题，则说明该应用的架构到了须要调整的时候，微服务架构则是针对以上问题的解决方案。下面咱们来看一下微服务架构究竟是什么？

微服务架构的核心思想是把应用按照功能划分红多个独立的服务，每一个服务都是独立运行的应用。

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

微服务架构的特征：

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

以下图所示，不一样服务之间存在调用关系，调用的方式能够是 REST 或 gRPC。

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

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

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

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

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

微服务架构的实现：

微服务架构所涵盖的内容很是普遍，对不一样角色的人员，其意义并不相同：

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

微服务架构的实践是一项系统化的工程，须要不少人的协同合做。做为开发人员，咱们更多关注的是如何完成服务的实现，但除了每一个服务自己的实现以外，还包括与其余服务的协做。

从实现的角度来讲，咱们须要考虑表中的这些因素。

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

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

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

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

微服务架构所包含的内容很是多，在本文中，我着重介绍了微服务架构的基本概念，从单体应用的问题来阐述引入微服务架构的必要性，以及微服务架构的应用具有的特征。

在微服务的实现上，还有许多具体的问题，好比如何拆分服务，服务之间如何协做，这些内容，都会在个人专栏中作具体的阐述。

感兴趣的话，你能够戳此查看个人专栏：《云原生微服务架构实战精讲》，本章节内容也会有更详细的补充，好比微服务架构存在哪些问题，下一讲我将详述“什么是 Docker 与容器化技术”，欢迎你来收听。