[服务器架构]微服务的深入思考

微服务有且仅有一种非常专项的功能，通过远程API来提供系统其余功能。举个例子：试想一下仓库的管理系统，这样的系统中微服务可能提供的一些功能有： 

• 接收库存
• 计算新的库存该存到什么地方
• 计算在仓库内将库存运往正确放置点的路线
• 为仓库员工分配运送路线
• 接收订单
• 计算仓库内指定一组订单的拣货路线
• 为仓库员工分配拣货路线

以上这些功能（可能还会有更多）都是由单个微服务实现的。每个微服务都有单独的运行线程，并且可以独立于其他微服务进行部署。同样每个微服务都有自己的专用数据库，尽管每个微服务都会与其他微服务协作与沟通。

一个系统中的不同微服务完全有可能在不同的平台上实现，一些可能在.NET上，另外一些在Erlang，其他的在Node.js上。只要能协调多语言的问题，各个微服务彼此正常沟通，就能奏效。HTTP是良好的沟通选择：上面所有提到的平台，还有很多其他平台都能很好的处理HTTP。当然也有符合微服务沟通规则的其他技术：例如一些队列、一些服务总线还有一些二进制协议。在这些技术当中，HTTP可能是支持最广泛的，相当容易理解，而且就像万维网所展示的那样很好用，总体来说是很好的方案。 

再次以仓库系统为例：该系统的一个微服务是分配拣货路线微服务。图一展示了“分配拣货路线微服务”从另一个协作微服务收到的请求：为指定员工设定了下一次的拣货路线。分配拣货线路微服务必须为员工找到合适的线路，而另一个微服务则完成计算最优路线的工作，分配拣货路线微服务只需收到拣货路线通知并确定如何为雇员分配路线。在分配拣货路线的微服务中，收到请求——分配指定员工的拣货路线，搜索数据库，找到合适的拣货路线，并从中选择一个返回给微服务调用。 

微服务架构是什么？ 

微服务是一种架构类型，属于轻量级的面向服务体系架构，这些服务都是严格专注于执行同一件事并把它做好。

使用微服务作为主要架构类型的系统是一个拥有大量协调微服务的分布式系统，每个微服务分管自己的进程。由于微服务之间紧密协作，每个微服务只提供拼图的一小块，而系统做为完整的作品存在。协作时，各服务彼此通过一个不绑定具体平台的轻量级媒介进行沟通，比如.NET，Java或者Erlang。如前所述，本书中所有微服务之间的沟通都是通过HTTP的，不过还有其他可选方案，比如队列、总线或者类似Thrift的二进制协议。 

在构建与维护复杂的服务器端软件系统时，微服务架构类型迅速流行起来。可以想见，这样一来：在传统的面向服务方法和整体架构（monolithic architectures）中，微服务都有大量潜在好处。在运作良好的前提下，微服务在可塑性、可扩展性与弹性方面都具有优势，并允许使用者只花费很短的时间就实现从开始到生产环境部署的过程。 

微服务特性 

虽然已经说了这么多，不过定义还很模糊。为了缩小微服务的界定范围，我们先来考察一下微服务的特性。在笔者理解中，微服务这个术语的特性是： 
1. 负责单个功能 

2. 单独部署 

3. 包含一个或多个进程 

4. 拥有自己的数据存储 

5. 一支小团队就能维护几个微服务 

6. 可替换的 

这张特性列表不但帮助识别微服务，还能够在发挥微服务优势（一个拥有可塑性、可扩展性与弹性的系统）的前提下协助界定与执行该服务，依次看下去。 

负责单个功能 

微服务在整个系统中只负责单个功能。这句话分解来说包含两部分内容：第一，微服务只有单个责任；第二，负责的是功能。单一责任原则有几种描述，其中一个传统的描述是： 

尽管这种说法特别提到了“类”，这一原则却不只适用于面向对象语言的类层面。通过微服务，这里在服务层面运用单一责任原则。另一种较新的说法也是描述单一责任原则的： 

这一原则适用于微服务：微服务应当正好实现一个功能。微服务必须只在功能改变时才跟着改变。此外，应当努力让微服务完全实现相关功能，这样在功能改变时微服务也得跟着改变。 

微服务系统的一个功能可能意味着几件事。首先，功能可能是业务方面的。业务功能就是系统所完成的、对系统的目的有贡献的事情——比如持续追踪用户的购物车或者计算价格。梳理一个系统拥有的独立业务功能有一个好办法，就是使用Domain Driven Design。第二，有时候功能可以是多个其他微服务需要利用的技术功能——例如集成到一些第三方系统中。技术功能并非是将系统分解成微服务的主因，而是由于微服务执行业务功能需要同样的技术能力而导致的结果。 

独立部署 

每个微服务都应当是单独部署的。也就是说：当你改变一个特定的微服务时，需要能够将微服务的变更部署到生产环境中，而无需部署或触及系统的其他部分。事实上，系统中的其他微服务应当在改动的微服务部署之时，还有新版本部署完成之后继续持续运行。 

试想一下电子商务网站：每次购物车微服务发生改变时，都应当能立即进行部署。同时价格计算微服务、推荐微服务、产品目录微服务等等应当继续运行并满足用户的请求。 

能够单独部署每个微服务非常重要，原因有好几个。其中一点是，在一个微服务系统中有很多微服务，每个微服务都会与其他几个相协作。各部分的开发工作同时完成，或者很多微服务并行。如果需要按同一步调部署所有或者很多微服务的话，管理部署很快就会变得捉襟见肘，特别是经常会导致高风险部署，这是我们很希望避免的。相反我们希望能够对每个微服务进行小变更部署，这样风险会更低。 

能够在系统的其他部分继续正常运行的时候部署单个微服务，构建过程必须牢记这一点：每个微服务必须打包到不同的构件或程序包中。同样地，部署过程本身还必须支持在其他微服务继续运行之时，独立部署变更的微服务。比如，每次将微服务部署到服务器的过程中，为了减少停机时间可以使用滚动部署的办法。 

微服务互动的方式也受到期望独立部署的影响。改变微服务接口必须在大多数情况下向后兼容，这样其他现有的微服务就可以继续按照与旧版本融合的方式与新版本集成了。此外，微服务互动的方式必须有弹性，每个微服务必须在其他微服务偶尔出错时继续保持最佳运行状态。一个微服务出错——比如因为部署时的短暂停机——必须不影响其他微服务运行，只是造成功能缩减或者进行时间稍长。 

包含一个或多个进程 

一个微服务由一个或多个进程组成，这个特性有两面性。首先，每个微服务独立于其他微服务运行；其次，每个微服务可以拥有不止一个进程。 

某微服务独立运行，是由于希望保持每个微服务尽可能独立于其他微服务继续运行。此外，为了独立部署微服务，那个微服务不能按照其他微服务的方式来运行。再用购物车微服务来举例：如果按照与产品目录微服务相同的方式运行，购物车代码可能对产品目录代码产生负面影响，这代表着购物车微服务与产品目录微服务之间紧密却不受欢迎的耦合。 

现在思考一下部署购物车微服务的新版本情况。要么得重新部署产品目录微服务，要么就得有某种动态代码加载功能，来替换正在运行中的购物车代码。前一个选项与微服务独立部署的原则完全相违背，后一个选项太过复杂而且起码有由于部署购物车微服务而造成产品目录微服务停机的风险。 

每个微服务可能包含不止一个进程，表面来看可能令人惊讶，毕竟这里尝试让每个微服务尽可能简单好控制，那么为什么要自找麻烦拥有不止一个进程呢？用电子商务网站做个比方：执行推荐算法会在电子商务网站上展示推荐选项，这些算法都在这个微服务所属的进程中运行，还存储了提供推荐需要的数据。这个数据可能存储在硬盘文件里，不过更有可能存在数据库里，在第二个进程中运行的数据库也属于这个微服务。一个微服务通常拥有2个或以上进程的需求，就是因为微服务需要实现所需要的一切，以提供包含诸如数据存储还有后台处理之类的功能。 

拥有自己的数据存储 

一个微服务包含数据存储，在该进程中存储所需的数据，正是由于我们希望微服务的范围是一个完整的功能。大多数业务功能需要一些数据存储，例如对于产品目录微服务来说，每个产品的信息需要存储下来。为了保持产品目录微服务与其他微服务的松散耦合性，存储的产品信息数据完全包含在产品目录微服务之中。由产品目录微服务确定何时、如何存储产品信息。其他微服务——比如购物车微服务——只能通过产品目录微服务的接口来访问产品信息，而永远不能直接访问产品目录存储。 

每个微服务包含自己的数据存储，这开启了根据每个微服务需求，为不同微服务使用不同数据库技术的可能性。产品目录微服务可能使用SQL服务器来存储产品信息，而购物车微服务可能用Redis来存储每个用户的购物车信息，推荐微服务则使用Elastic Search索引来提供推荐服务。为每个微服务所选择的数据库技术是执行的一部分，对其他微服务来讲是隐藏的。将数据库技术与每个微服务需求进行混合配对的好处在于，每个微服务可以使用最适合的数据库。对开发时间、性能和可扩展性很有好处，不过也带来了成本问题。数据库技术上非常复杂，学习使用和在生产环境上运行一个可靠的数据库都不容易。为微服务选择数据库信息时，应当考虑取舍的问题。不过也要记住，由于微服务拥有自己的数据存储，稍候切换到另一个数据库也是可行的。 

小团队就能维护 

到现在本文并未讨论太多微服务的规模问题，虽然微服务中的“微”暗示着这些服务规模很小。但这里并不认为讨论微服务应当有几行代码，需求/用例有多少或者应当执行的功能点有几个这些有什么意义。所有这些取决于微服务所提供功能的复杂性。真正有意义的是考虑维护微服务的工作量。指出微服务规模大小的一条经验法则是：一个5人小团队就应当能够维护几个或者更多的微服务。维护一个微服务包括保持其正常运行并达成目标：开发新的功能、从发展到过大规模的微服务中分解出新的微服务、监控测试与修复bug及其他。考虑到一个小团队应当能够完成几个微服务的所有这些工作，你应当对典型的微服务规模有概念了。 

可替换的 

一个微服务是可替换的，代表着它可以在合理的时间框架内从头重写。也就是说，维护该微服务的团队可以决定用全新的实现来替代现有的，并且不会打乱正常工作的进程。这条特性也是微服务规模的一条约束：如果一个微服务成长地太大，替代成本就会过高，只有保持小型才能让重写比较现实。 

为什么团队会决定重写微服务？一个原因可能是代码太乱，另一个原因是微服务不能在生产环境中运行良好。尽管这些情况并非所愿，却出体现了微服务的优势。即便努力构建微服务，时间造成的需求变更可能促使现有的实现方式无法满足需求而需要变更。而且随着时间过去，代码可能会由于初始设计周折太多而变成一团乱麻。性能要求可能会需要大幅提升，而现有设计无法满足。如果一个微服务小到在合理时间框架内便能重写，偶尔出现这些情况都是ok的。了解现有实现所有知识的同时，再结合新需求考虑，就能简单地完成重写工作。