原博文地址

译文地址

从文章发布时间来看，刚好处在微服务这一概念很火（流行在社交和学术研究）但却又很模糊（在当时还没有对于微服务能被大众接收的定义）的时间。Martin Fowler的这篇博文算是给大众指出一个探究“微服务架构”的方向。同时可以结合Martin Fowler的这次演讲视频学习（需要柯-学-上-网），内容就是对微服务架构定义的介绍，是对原博文的提炼。

个人认为，学习微服务架构的目标就是能给一个复杂的单体架构应用系统做有效的服务拆分（需要仔细考虑服务的职责边界），开发完成后实现自动化的独立部署和维护。前提是能理解微服务架构出现的背景，即从 传统的单体架构 向 面向服务架构 的发展中，到底有什么问题需要被解决。「微服务架构是“面向服务架构（SOA）”的一个子集」。

微服务的定义

微服务，是以开发一组小型服务的方式来开发一个独立的应用系统，里面的每个小型服务都独立运行在各自的进程中，相互通过api来进行通信。

每个小型服务的构建都是围绕其在业务流程中的功能，能通过全自动部署的机制来进行独立部署（独立升级、独立替换，符合组件化的特征）。

这些微服务可以使用不同的语言来编写（可以根据语言特性进行技术选型，提升技术创新），并且可以使用不同的数据存储技术（适应业务需求，从响应速度、延展等维度进行考虑）。

对这些微服务我们仅做最低限度的集中管理（总线）。

特性一：组件化和多服务

组件是一个可被独立进行更换和升级的软件单元。

传统的单体应用系统是内嵌了多个组件，但它们依旧是运行在同一个进程里面的，只是在需要被调用时跳转到指定的内存地址进行计算。一旦需要针对某个组件进行修改，就要重新部署整个应用系统。

而微服务通过将系统根据功能来划分为多个服务并独立部署，相互之间通过明显的接口（HTTP接口）来进行通信调用服务。与传统的单体应用系统相比，修改成本会更低，只需修改服务的内部实现并重新部署此服务。

不足之处在于：远程调用服务的成本 会比在 同一进程内调用函数更高，且不能严格控制api接口、不能方便地修改服务之间的职责。

简单的应用系统是不应该采用微服务架构的，成本太高了(服务的职责划分颇为费时、部署服务器的成本)。

特性二：围绕“业务功能”组织团队

既然整个系统已经被划分为多个微服务，那开发团队还会像传统那样被组建成用户界面团队、服务器端团队和数据库团队吗？答案是否定的。每个微服务都应成为独立部署、独立升级和工作的模块，其中均需要从上述三个基本维度来进行构建。全部微服务模块均由同样的用户界面团队、服务器端团队和数据库团队完成的话，很可能会导致每个微服务之间存在代码上的紧耦合。

即划分开发组织团队的标准并非是其技术类型，而是以所负责的“业务功能”。每个团队都是全栈的，拥有软件开发所需的全方位的技能：用户体验、数据库和项目管理。

比方说某个在线视频网站会用到上述多套解决方案，把这些都看作是内部多个微服务的实现。每个团队根据具体的业务能力来构建和维护多套产品，各自能被拆分为独立的服务，同时还能达到用户体验要求。

作者为了更好地让大家理解，引入了康威定律。。

任何设计（广义上的）系统的组织，都会产生这样一个设计，即该设计的结构与该组织的沟通结构相一致。

​ ——梅尔文•康威（Melvyn Conway）, 1967年

特性三：“做产品”而非“做项目”

即将每个微服务模块看作独立的产品来进行维护，只要服务还在线上，就需要原开发团队对其进行负责。（国内中小型公司估计很难是做到这一点，非技术出身的管理者更加愿意从企业经营效益的角度来进行组织架构和人员的调整）

特性四：“智能端点”与“傻瓜管道”

前者“智能端点”的做法指的是微服务之间相互调用时，都有清晰明确的目标地方，我们只需要给每个微服务约定好调用接口，利用 RESTAPI 来完成资源调用即可。以便减少微服务间的耦合（接口一旦定下来了可就不能轻易变更）。

后者“傻瓜管道”则是由消息总线来把微服务的调用请求，按照目标来发送给合适的微服务处理，异步返回处理结果（消息队列）。

给微服务选择通讯方式还得根据自身的条件进行吧，至少微服务间的调用有一定的延迟。。

特性五：“去中心化”地治理技术

需要根据业务特点，选择合适的工具（技术栈）来完成构建服务。这样可以更好地提高团队的技术创新能力，这也是开发们提升技术拓展能力的好机会把。

特性六：“去中心化”地管理数据

数据的持久化管理应该集中在一起还是由各自微服务来完成呢？这需要参考业务上对于数据一致性的要求以及为修复“数据不一致”所付出的成本。微服务架构推崇各自服务完成自己的数据持久化任务，这样可以减轻统一数据库所带来的无休止的事务混杂问题，且数据库类型的选择也应该遵循特性五。

特性七：“基础设置”自动化

持续交付这个目标是肯定要达到的。跑通大量自动化测试，然后在新的环境下（甚至热更新）进行自动化部署，这就需要“基础设置”自动化。

特性八：“容错”设计

容错是要求，而不是特征。微服务架构决定了每类服务都不是运行在同一个进程中，服务之间的通讯联系有可能出现超时或无响应。每一类微服务由多台实例部署服务，当其中出现了某些实例挂掉以后，势必会导致其他实例的依赖增加、响应延迟增加等问题，最终就是导致请求线程的阻塞。（负载均衡？服务发现？）

容错设计不但但体现在服务响应部分，还包括用户体验上的设计：是直接抛出错误（体验极差）还是提供缓存或重试选择？

特性九：进化设计

微服务架构应该是从单体架构系统进化而成的一个阶段，而非系统架构模式中的的银弹。具备足够简单模型的应用系统一开始就应该采用单体架构，因为微服务架构引入了分布式计算、复杂的沟通和异步处理，这些加在一起已经足够复杂了。

还要考虑什么？

除此之外，还要考虑数据一致性要求（微服务架构很难达到高读数据一致性），内部模块重构（这就涉及到了微服务的边界界定，一旦定下来以后进行模块重构，会被边界所限定，重构的工作将很有可能涉及到其他微服务模块）。

微服务：部分部署能力（特性一）、可用性（部分服务挂掉不代表这个系统不能用）、持续模块化、可部署在多个不同的平台（因为整个系统未必是由同一类语言所编写的）。

例如考虑到微服务便捷部署的特点，你家的服务器配置是不是也能跟得上速度呢？上云服务部署实例还是有专人负责配置呢（事实上在云中部署更快）？例如怎样设计系统的监控？怎样才能尽早地发现问题？

以上是我的一点拙见。