有关微服务的多种解释与理解【摘自网络】，不完全赞同的文章

1. 负责单个功能

2. 单独部署

3. 包含一个或多个进程

4. 拥有自己的数据存储

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

6. 可替换的

负责单个功能

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

“当需要修改某个类的时候原因有且只有一个（"There should never be more than one reason for a class to change."）” -- Robert C. Martin SRP: 单一责任原则

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

聚合因同一理由变化的东西，分离因不同理由而变化的东西。（"Gather together the things that change for the same reasons. Separate those things that change for different reasons."）-- Robert C. Martin单一责任原则

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

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

独立部署

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

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

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

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

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

包含一个或多个进程

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

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

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

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

拥有自己的数据存储

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

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

小团队就能维护

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

可替换的

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

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

===================================================================================================================