架构演进及微服务架构介绍

总述

近年来，微服务架构一直是互联网技术圈的热点之一，越来越多的互联网应用都采用了微服务架构作为系统构建的基础，很多新技术和观念如Docker、Kubernetes、DevOps、持续交付、Service Mesh等也都在关注、支持、和跟随微服务架构的发展。
接下来，会概要的介绍微服务架构：包括微服务架构是如何演进的，微服务架构的主要流派，当前主流的云原生应用与微服务之间的关系。

1.1 微服务架构的出现

从单体应用架构发展到SOA架构，再到微服务架构，应用架构经历了多年的不断演进。微服务架构不是凭空产生的，而是技术发展的必然结果，分布式云平台的应用环境使得微服务代替单体应用成为了互联网大型系统的架构选择。目前，虽然微服务架构还没有公认的技术标准和规范草案，但业界已经有了一些很有影响力的开源微服务架构解决方案，在进行微服务化开发和改造时可以进行相应的参考。

1.1.1 单体应用架构
与微服务架构对比的是传统的单体应用。Web应用程序发展的早期，大部分Web工程是将所有的功能模块打包到一起部署和运行，例如Java应用程序打包成一个war包，其他语言（Ruby、Python或者C++）编写的应用程序也有类似的做法。单体应用的实现架构类似如下图中的电影售票系统：

这个电影售票系统采用分层架构，按照调用顺序，从上到下为表示层、业务层、数据访问(DAO)层、DB层。表示层负责用户体验；业务层负责逻辑：包括电影、订单和用户三个模块；数据访问层负责DB层的数据存储，实现增删改查的功能。业务层定义了应用的业务逻辑，是整个应用的核心。在单体应用中，所有这些模块都集成在一起，这样的系统架构就叫做单体应用架构，或称为巨石型应用架构。单体应用架构是最早的应用形态，开发和部署都很简单。在中小型项目中使用单体应用架构，能体现出其优势，且单体应用的整体性能主要依赖于硬件资源和逻辑代码实现，应用架构自身不需要特别关注。

单体应用的集成非常简洁，IDE集成开发环境和其他工具都擅长开发一个简单应用；单体应用易于调试。由于一个应用包含所有功能，所以只需要简单运行此应用即可进行开发测试；单体应用易于部署，只需要把应用打包，拷贝到服务器端即可；通过负载均衡器，运行多个服务实例，单体应用可以轻松实现应用扩展。

但是，随着应用项目变得复杂，开发团队不断扩张之后，单体应用的不足和弊端将会变得很明显，主要有以下不足：
a.可靠性： 每个bug都可能会影响到整个应用的可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个bug，比如内存泄露，都可能拖垮整个进程。
b.复杂性高： 单体应用巨大的代码库可能都会令人望而生畏，特别是对团队新成员来说，应用难以理解和迭代，进而导致开发速度减慢。由于没有清晰的模块边界，模块化会逐渐消失。
c.持续部署困难： 巨大的单体应用本身就是频繁部署的一大障碍。为了更新一个组件，必须重新部署整个应用。这会中断那些可能与更改无关的后台任务（例如Java应用中的Quartz任务），同时可能引发其他问题。另外，未被更新的组件有可能无法正常启动。重新部署会增加风险，进而阻碍频繁更新。
d.扩展能力受限： 单体架构只能进行一维扩展。一方面，它可以通过运行多个应用服务实例来增加业务容量，实现扩展。但另一方面，不同的应用组件有不同的资源需求：有的是CPU密集型的，有的是内存密集型的。单体架构无法单独扩展每个组件。
e.阻碍技术创新： 单体应用往往使用统一的技术平台或方案解决所有问题，团队的每个成员都必须使用相同的开发语言和架构，想要引入新的框架或技术平台非常难。单体架构迫使团队长期使用在开发初期选定的技术栈，比如选择了JVM的语言，此时以非JVM语言编写的组件就无法在该单体架构的应用中使用。

1.1.2 SOA架构

面向服务的架构（SOA）是Gartner与于20世纪90年代中期提出的。2002年12月，Gartner提出“面向服务的架构”是现代应用开发领域最重要的课题之一。

SOA的核心主体是服务，其目标是通过服务的流程化来实现业务的灵活性。服务就像一堆“元器件”，这些元器件通过封装形成标准服务，它们有相同的接口和语义来表达规则。但服务要组装成一个流程和应用，还需要有效的“管理”，包括如何注册服务，如何发现服务，如何包装服务的安全性和可靠性，这些就是SOA治理。SOA治理是将SOA的一堆元器件进行有效组装。这是形成一个“产品”的关键，否则那些永远是一堆元器件，而无法形成一个有机整体。

完整的SOA架构由五大部分组成：基础设施服务、企业服务总线、关键服务组件、开发工具、管理工具等。
a.基础设施： 为整个SOA组件和框架提供一个可靠的运行环境，以及服务组件容器，它的核心组件是应用服务器等基础软件支撑设施，提供运行期完整、可靠的软件支撑。
b.企业服务总线： 提供可靠消息传输、服务接入、协议转换、数据格式转换、基于内容的路由等功能，屏蔽了服务的物理位置、协议和数据格式。
c.关键服务组件： SOA在各种业务服务组件的分类。
d.开发工具和管理工具： 提供完善的、可视化的服务开发和流程编排工具，包括服务的设计、开发、配置、部署、监控、重构等完整的SOA项目开发生命周期。

具体来说，就是在分布式的环境中，将各种功能都以服务的形式提供给最终用户或者其他服务。企业级应用的开发多采用面向服务的体系架构来满足灵活多变、可重用性的需求。它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

SOA是在企业计算领域中提出的，目的是要将紧耦合的系统，划分为面向业务的、粗粒度、松耦合、无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构的系统。基于这些基础的服务，可以将业务过程用类似BPEL（业务流程执行语言）流程的方式编排起来，BPEL反映的是业务处理的过程，这些过程对于业务人员更为直观。企业还需要一些服务治理的工具，比如服务注册库、监控管理等。在企业计算领域，如果不是交易系统的话，并发量都不是很大，所以大多数情况下，一台服务器就可以容纳许多的服务，这些服务采用统一的基础设施，可能都运行在一个应用服务器的进程中。虽然说是SOA架构，但还可能是单一的系统。

1.1.3 微服务架构

微服务最早是由Martin Fowler 与 James Lewis于2014年共同提出的，需要了解细节的读者可以阅览https://martinfowler.com/articles/microservices.html。其实Martin先生并没有给出明确的微服务定义。根据其描述，微服务的定义可以概括如下：微服务架构是一种使用一些列粒度较小的服务来开发单个应用的方式；每个服务运行在自己的进程中；服务间采用轻量级的方式进行通信（通常是HTTP API）；这些服务是基于业务逻辑和范围，通过自动化部署的机制来独立部署的，并且服务的集中管理应该是最低限度的，即每个服务可以采用不同的编程语言编写，使用不同的数据存储技术。

如今，微服务架构已经不是一个新概念了，很多业界前沿互联网公司的实践表明，微服务是一种渐进式的演进架构，是企业应对业务复杂性，支持大规模持续创新行之有效的架构手段。

1.组成
微服务架构是一种比较复杂，内涵丰富的架构模式：它包含很多支撑“微”服务的具体组件和概念，其中一些常用的组件及其概念如下：
a.服务注册与发现： 服务提供方将己方调用地址注册到服务注册中心，让服务调用方能够方便地找到自己；服务调用方从服务注册中心找到自己需要的服务的地址。
b.负载均衡： 服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，服务节点选择的过程对服务调用方来说是透明的。
c.服务网关： 服务网关是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等。
d.集成框架： 微服务组件都以职责单一的程序对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
e.调用链监控： 记录完成一次请求的先后衔接和调用关系，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。
f.支撑平台： 系统微服务后，各个业务模块经过拆分变得更加细化，系统的部署、运维、监控都比单体应用架构更加复杂，这就需要将大部分的工作自动化。现在，Docker等工具可以给微服务架构的部署带来较多的便利，例如持续集成、蓝绿发布、健康检查、性能健康等等。如果没有合适的支撑平台或工具，微服务架构就无法发挥它最大的功效。

2.优点
微服务架构模式又很多优势可以有效地解决单体应用扩大之后出现的大部分问题。首先，通过将巨大单体式应用分解为多个服务的方法解决了复杂性问题。在功能不变的情况下，应用分解为多个可管理的模块或服务。每个服务都有一个用RPC或者消息驱动API定义清楚的边界。微服务架构模式为采用单体式编码方式很难实现的功能提供了模块化的解决方案。由此，单个服务变得很容易开发、理解和维护。

其次，微服务架构模式使得团队并行开发得以推进，每个服务都可以专门开发团队来开发。不同团队的开发者可以自由选择开发技术，提供API服务。这种自由意味着开发者不需要被迫使用之前采用的过时技术，他们可以选择最新的技术。甚至于，因为服务都是相对简单的，即使用新技术重写以前的代码也不是很苦难的事情。

再次，微服务架构模式中每个微服务都是独立部署的。理想情况下，开发者不需要协调其他服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。

最后，微服务架构模式使得每个服务易于独立扩展。

3.挑战
微服务的一些想法是好的，但在实践中也会呈现出其复杂性，具体如下：
a.运维要求较高： 更多的服务意味着需要更多的运维投入。在单体架构中只需要保证一个应用的正常运行即可，而在微服务中，需要保证几十个甚至几百个服务的正常运行与协作，这带来了巨大的挑战。
b.分布式固有的复杂性： 使用微服务构建的是分布式系统。对于一个分布式系统来说，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。
c.接口调整成本高： 微服务之间通过接口进行通信。如果修改某个微服务的API，可能所有使用了该接口的微服务都需要做调整。
d.重复劳动： 很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，导致代码重复。
e.可测试性的挑战： 在动态环境下，服务间的交互会产生非常微妙的行为，难以进行可视化及全面测试。

1.2 微服务架构的流派

常见的微服务架构方案有四种，分别化生寺ZeroC IceGrid、基于消息对垒、Docker Swarm和Spring Cloud。下面分别介绍这四种方案。

1.ZeroC IceGrid
ZeroC IceGrid是基于RPC框架Ice发展而来的一种微服务架构，Ice不仅仅是一个RPC框架，它还为网络应用程序提供了一些补充服务。Ice是一个全面的RPC框架，支持C++、C#、Java、JavaScript、Python等语言。IceGrid具有定位、部署和管理Ice服务器的功能，具有良好的性能与分布式能力，下面具体介绍IceGrid的功能。

Ice的DNS。DNS用于将域名信息映射到具体的IP地址，通过域名得到该域名对应的IP地址的过程叫做域名解析。Ice Grid为Ice提供了类似的服务；它允许Ice客户端通过简单的名称来查找Ice对象。Ice客户端可以通过提供此对象的完整寻址信息来访问服务器中的Ice对象，例如chatRoom1：ssl -h demo.zeroc.com -p 10000。这样的硬编码虽然很简单，但缺乏灵活性。因为需要为Ice服务器（本例中端口为10000）选择一个固定的端口号，因此将Ice服务器移到不同的主机上需要更新其客户端。

IceGrid提供了对这种寻址信息使用符号名称的选项，例如chatRoom1@chatRoomHost。当Ice客户单尝试访问chatRoomHost中的对象时，它会要求IceGrid提供与此符号名称关联的实际地址。例如，IceGrid返回-h demo.zeroc.com -p 65431，客户端就可以直接并透明的链接到服务器。IceGrid架构如图：

a.服务器部署： 若直接通过IP地址+端口号的方式，当Ice客户端尝试连接到未运行的服务器时，连接将会失败。通过符号或间接寻址，IceGrid有机会检查目标服务器是否正在运行，并在服务器未运行时启动或重新启动服务器。可以配置IceGrid以各种方式启动服务器，手动（通过管理命令）、按需（无论何时请求服务器）和IceGrid始终保持服务器运行。
b.服务器的复制： IceGrid允许部署同一服务器的多个副本，并可以配置IceGrid将符号名称解析到此服务器副本的策略。可以在所有副本中对客户端进行负载平衡，或者使用主备配置，客户端只要保持可用状态，就使用主备配置。
c.管理和监控： IceGrid的管理工具可以完全控制已部署的应用程序。诸如启动服务器或修改配置设置等活动只需单机鼠标即可。

2.基于消息队列：
在微服务架构的定义中讲到，各个微服务之间使用“轻量级”的通信机制。所谓轻量级，是指通信协议与语言无关，与平台无关。微服务之间的通信方式有两种，同步和异步。同步方式有RPC，REST等；除了标准的基于同步方式的微服务架构，还有基于消息队列异步方式通信的微服务架构。
在基于消息队列的微服务架构的方式中，微服务之间采用发布消息与监听消息的方式来实现服务服务之间的交互。
基于消息队列的微服务架构是全异步通信模式的一种设计。各个组件之间没有直接的耦合关系，也不存在服务接口与服务调用的说法，服务之间通过消息来实现彼此的通信与业务流程的驱动，基于消息队列的微服务架构应用的案例并不多，更多的体现为一种与业务相关的设计经验。每个公司有着不同的实现方式，缺乏公认的设计思路和参考价值，也没有形成一个知名的资源平台。因此，如要实现这种微服务架构，需要项目组自己从零开始去设计实现一个微服务架构基础平台，这可能会造成项目的成本且风险比较大，决策之前需要进行全盘思考与客观评价。

3.Docker Swarm：
Swarm项目是Docker公司发布的三剑客之一，用来提供容器集群服务，目的是更好的帮助用户管理多个Docker Engine，方便用户使用，通过把多个Docker Engine聚集在一起，形成一个更大的Docker Engine，对外提供容器的集群服务。同时这个集群对外提供Swarm API，用户可以像使用Docker Engine一样使用Docker集群。

Docker Swarm对外提供Docker API，自身轻量，学习成本，二次开发成本都比较低，是一个插件式框架，从功能上讲，Swarm是类似于Google开源的Kubernetes微服务架构平台的一个产品。

4.Spring Cloud:
Spring Cloud是一个基于Spring Boot实现的云原生开发工具，是一系列框架的集合，当添加这些工具库到应用后会增强应用的行为。Spring Boot秉持约定优于配置的思想，因此可以利用这些组件基本的默认行为来快速入门，并在需要的时候可以配置与扩展。以创建解决自定义解决方案。

Spring Cloud利用Spring Boot的开发便利性，巧妙的简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以基于Spring Boot组件进行开发，做到一键启动和部署。Spring Cloud并没有重复制造轮子，他只是将目前比较成熟 、经得起实际考验，优秀的开源服务框架整合起来，通过Spring Boot进行封装，屏蔽调复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

以下是Spring Cloud的核心功能：
分布式/版本化配置
服务注册和发现
服务路由
服务与服务之间的调用
负载均衡
断路器
分布式消息传递

还有很多基础的功能没有列出，每个功能对应Spring Cloud中的一个组件，包括Spring Cloud Config、Spring Cloud Netflix（Eureka、Hystrix、Zuul、Archaius … ）、Spring Cloud Bus等组件

1.3 云原生与微服务

提及云原生，首先需要了解一下CNCF，即云原生计算基金会，2015年由谷歌牵头成立，基金会成员目前已有一百多个企业与机构，包括亚马逊、微软、思科等巨头。目前CNCF所托管的应用已达14个，知名的项目有Kubernetes、Prometheus、Envoy等。

1.云原生
CNCF宪章中给出了云原生应用的三大特征，概括如下：
容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。
动态管理：通过集中式的编排调度系统来动态管理和调度。
面向微服务：明确服务间的依赖，互相解耦

云原生包含了一组应用的模式，用于帮助企业快速、持续、可靠、规模化的交付业务软件。如图所示：云原生由微服务架构、DevOps和以容器为代表的敏捷基础架构组成。

2.12原则
12原则（12-Factors）经常直译为12要素，12原则由公有云PaaS的先驱Heroku于2012年提出的，目的是告诉开发者如何利用云平台提供的遍历来开发更具可靠性和扩展性、更加易于维护的云原生应用。12原则包括：
基准代码
显示声明依赖关系
在环境中存储配置
把后端服务当做附加资源
严格分离构建、发布和运行
无状态进程
通过端口绑定提供服务
通过进程模型进行扩展
快速启动和优雅终止
开发环境和线上环境等价
日志作为时间流
管理进程

另外还有补充的三点：API声明管理、认证和授权、监控和告警

12原则提出来已有八年多，12原则的有些细节可能已经不那么跟得上时代，也有人批评12原则的提出从一开始就有过依赖Heroku自身特性的倾向。不过不管怎样，12原则依旧是业界最为系统的云原生应用开发指南。

3.容器化
Docker是一个开源引擎，可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器。最近几年Docker容器化技术很火，在各种场合都能够听到关于Docker的分享。Docker让开发工程师可以将他们的应用和依赖都封装到一个可移植的容器中。Docker根本的想法是创建软件程序可移植的轻量容器，让其可以在任何安装了Docker的机器上运行，而不用关心底层操作系统。

Docker可以解决虚拟机能够解决的问题，同时也能够解决虚拟机由于资源要求过高而无法解决的问题。其优势包括：
隔离应用依赖。
创建应用镜像并进行复制
出那个键容器分发的、即启即用的应用
允许实例简单、快速的扩展
测试应用并随后销毁他们

虽然自动化运维工具可以降低环境搭建的复杂度，但任然不能从根本上解决环境的问题。在看似稳定而成熟的场景下，综合使用Docker显然能带来更多的好处。

一旦拥抱了容器，这就需要一个编排框架来调度和管理容器。最常见的编排框架有Kubernetes、Mesos、Docker Swarm。编排框架是容器平台的关键组成部分。

4.DevOps
DevOps是软件开发人员Dev和IT运维技术人员Ops之间的合作，目标是自动执行软件交付和基础架构更改流程，使得构建、调试、发布软件能够更加快捷和可靠。它创造了一种文化和环境，可在其中快速、频繁且更可靠地构建、测试和发布软件。通过DevOps流水线加上Docker容器，可以实现自动化工程管理，实现开发、测试环境的自动申请和构建。通过Docker标准化打包应用配置和环境，可以生成轻量容器镜像，并使用镜像方式迭代开发、测试、部署、加速应用上线，自动化运维在合力保障应用高可用的前提下，能够提升资源利用率，降低成本。

5.微服务
微服务将单体业务系统分解为多个可独立部署的服务。这个服务通常只关注某项业务，或者最小可提供业务价值的“原子服务单元”。
微服务架构以下优势：
当人们将业务领域分解为可独立部署的环境时，能够将相关的变更周期解耦。只要变更限于单一有限的环境，并且服务继续履行其现有合约。那么这些变更可以独立于其他业务来进行和部署。其结果是实现了更频繁和快速的部署，实现了持续的价值流动。

扩展更多的部署组件本身可以加快部署。在原本的单体应用中，由于沟通和协调的开销，在添加更多的人手时，往往会使软件开发流程变得更长。

可以加快采用新技术的步伐。大型单体应用程序架构通常与对技术堆栈的长期保证有关。

微服务提供独立、高效的服务扩展。单体架构也可以扩展。但要求我们扩展所有组件，而不仅仅是哪些负载较重的组件。当且仅当相关联的负载需要它时，才缩放微服务。