架构风格：微服务

本文探讨：

• 什么是微服务
• 微服务的约束
• 微服务对架构属性的影响

什么是微服务

「微服务」是一种架构风格，也就是说，「微服务」是一组架构约束。

前面说到REST是一种复合式的架构风格，微服务也是！微服务的约束面更广，它对开发过程和开发人员也进行了约束！

微服务的约束

MartinFlower在Microservices一文中，详细阐述了微服务所须要具备的约束！

- Componentization via Services：基于服务的组件化
- Organized around Business Capabilities：围绕业务能力进行组织
- Products not Projects：产品而不是项目
- Smart endpoints and dumb pipes：智能终端和静默管道
- Decentralized Governance：去中心化治理
- Decentralized Data Management：去中心化数据管理
- Infrastructure Automation：基础设施自动化
- Design for failure：容错性设计
- Evolutionary Design：进化式设计

实际上这些约束回答了架构设计所关心的几个问题：

• 系统如何切分:围绕业务能力进行组织，去中心化数据管理
• 模块之间如何通讯:基于服务的组件化，智能终端和静默管道
• 如何进行技术选型:去中心化治理
• 容错性:容错性设计
• 扩展性:产品而不是项目,进化式设计
• 可维护性:基础设施自动化

下面一个个的说明！

系统如何切分？

在「架构风格：万金油CS与分层」一文中，最后提到，通常状况下，当你不知道一个系统使用何种架构比较好时，能够先使用分层架构。分层架构就是将系统一层一层的切分，下层为上层提供服务。

每一层的边界是什么呢？是「系统功能」！展示、业务逻辑、数据存储。你会发现，这种切分方式和业务自己没有任何关系，因此才是「万金油」！

另外，这种切分方法也将开发人员划分红了前端、后端、DBA！这是目前主流的作法，好像也没有出现什么大问题！

若是你在大公司待过，你就会发现进行一个需求变动是多么麻烦的一件事。即便一个很简单的需求，均可能要全部团队都参与进来。

致使这个问题的缘由是什么呢？是沟通成本！

项目管理算法的复杂度是O（N 2），当人员变得愈来愈多时，沟通成本成倍增加：

• 5人团队，须要沟通的渠道是 5*(5–1)/2 = 10
• 15人团队，须要沟通的渠道是15*(15–1)/2 = 105
• 50人团队，须要沟通的渠道是50*(50–1)/2 = 1,225
• 150人团队，须要沟通的渠道是150*(150–1)/2 = 11,175

咱们都知道「技术是为业务服务的」！若是一个架构和业务没有关系，如何为业务服务呢？若是沟通要花费大量的时间，如何快速推动项目呢？

因此，微服务「围绕业务能力进行组织」！

• 既包括了系统的切分
• 也包括了对人员的组织

由于康威定律提到：

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." - Melvin Conway (1967).

在微服务中，每一个模块（这里的模块和咱们日常所理解的模块有些区别，它的粒度更大，因此在微服务里通常称为是服务，下面均使用「服务」）都是一个完整的业务系统！包括了展示、业务逻辑和数据存储！相应的，负责开发的人员须要具有开发这个服务所须要的全部技能！

也就是说，在微服务中服务的边界是业务的边界！

这很相似韩都衣舍的「以产品小组为核心的单品全程运营体系（IOSSP）」！将企业划分为“小集体”，像自由自在重复分裂的“阿米巴”——以各个“阿米巴”为核心，自行制订计划，独立核算，持续自主成长。以3人一组的产品组为例，这三我的分别是设计师、页面制做、库存管理员。这三人全权负责某一单品的页面制做、款式设计、尺码以及库存深度的预估等工做。

对应到微服务中，即两到三我的负责一个服务，这个服务包含了完整的业务流程，开发人员须要掌握开发这个服务所须要的完整的技能，包括UI、编程、DBA!

这里的难点是：

• 一是要划分好业务边界，使得每一个服务可以高内聚、低耦合！
• 二是制定规范，利于各个服务之间的通讯
• 三是人员技能的要求更高

如何进行业务划分，须要根据具体的业务来具体进行。这里暂不展开。只提一点，就是要将事务考虑在内！

就是说在切分系统的时候，要考虑事务问题！咱们都知道远程事务是一个比较难处理的问题！两阶段提交、三阶段提交都不能很好的解决分布式事务问题！Paxos算法过于复杂，且性能较差。

因此微服务的建议是：

• 尽可能保证事务在一个服务中执行
• 经过补偿的方式来弥补事务操做的问题

服务如何通讯？

对于通常系统来讲，咱们都是使用的进程内通讯，即经过调用同一内存内的方法的方式进行通讯！公用的代码咱们能够以「库」的形式进行组织，避免代码重复！这种系统咱们通常称为「单体系统」！

「单体系统」的伸缩性不理想！好比说，双11须要作个活动，瞬间用户量大增！若是须要应对流量峰值，就须要对系统进行扩容。可是由于是单体系统，扩容只能总体扩容，而实际上须要扩容的只是那个活动页面！这就致使了资源的浪费。另一个问题就是，若是这个活动致使了系统崩溃，这将致使这个系统的全部功能都不能使用！

一种解决方案是进行「服务化」！即将须要多个系统公用的逻辑或TPS较高的模块独立部署，经过进程间通讯的方式，进行服务调用。好比上面的活动模块，当活动模块以服务的方式对外服务后，须要扩容时，只须要扩容活动服务就能够了。同时，若是活动服务出现了问题，只会致使这个活动相关内容没法访问，而不会影响系统的其它功能。今年双11淘宝的地址服务就挂了，可是并不影响淘宝自己的访问。

这里所说的「服务化」是使用dubbo这类服务化框架进行的服务化，而不是使用ESB的SOA！

基于ESB的SOA主要是为了将企业中的各个系统链接起来！ESB像一根「聪明」的管道，用来链接各个「愚笨」的节点。为了集成不一样系统，不一样协议的服务，ESB作了不少事情：

• 消息路由
• 编排
• 转换
• 业务处理规则

这就致使ESB很重、很复杂。这也是基于ESB的SOA被人诟病的一个缘由。

dubbo这类服务化框架主要解决的是运行时代码复用、系统伸缩性以及高性能问题！可是服务粒度相对较小，带来的问题就是维护的成本相对较高！

而微服务能够说作了一些折中：

• 服务粒度较大，包含了一个完整的业务的展现、逻辑和存储。相对的数量就较服务化少，维护相对较容易
• 以进程间通讯的方式提供服务。包括对外服务、以及其它服务。保证了伸缩性。
• 业务逻辑处理都在服务内部进行，通讯组件只提供单纯的通讯功能。保证了简单性。

这样既摆脱了繁重的ESB，也下降了维护难度！

如何进行技术选型？

对于「如何进行技术选型」，微服务不强制开发平台！由于「没有银弹」！微服务偏向于「适合的工具解决适合的问题」！

每一个程序员都有本身喜欢的技术体系！有喜欢Java的、有喜欢.Net的、有喜欢C++的，还有喜欢Lisp的。。。。

那开发系统时须要选择哪一种技术体系呢？按微服务的观点就是：哪一种技术合适就用哪一种技术吧！这个服务须要高并发，能够用Go来进行开发！这个服务须要快速推动，能够用PHP！这个服务须要稳定，能够用Java！看起来很完美！

而实际上内，这致使的是不可控！为何Java语言会被不少企业使用？其中一个缘由就是可控！

举个例子，国内公司的技术栈相对比较单一！好比，公司的主流语言是Java,.Net,PHP等，其它语言就只是辅助！通常不会有两种、甚至三种主流语言！
假设一家公司的主流语言是Java！开发一个系统，可能须要10我的。那公司能够招5~6个通常的，2~3个不错的，1个牛逼的！公司只要稳住那个牛逼的就好了！若是有人走了，只要其余人顶上就好了！
而若是每种服务都使用不一样的语言，那一个系统使用了三个左右的语言，每种语言得有个熟练掌握的吧？每种语言，公司都得稳住个相对牛逼的吧？成本高不说，难度也大了很多！

容错性

系统按照业务切分为一个个的服务，相对单体应用来讲，运行的系统多了，系统总体不可用的概率下降了，可是单个服务出现问题的概率却变大了！这就须要微服务系统须要有比单体应用更好的容错性！

任何服务可能由于供应商的不可靠而故障，客户端须要尽量的优化这种场景的响应。与单体构架相比，这是一个缺点，由于它带来额外的复杂性。这将让微服务团队时刻须要关注服务故障的状况下的用户体验。
因为服务可能随时出现问题，因此快速故障检测，甚至自动恢复就变动很是重要。微服务应用把实时的监控放在应用的各个阶段中，检测构架元素（每秒数据库的接收的请求数）和业务相关的指标（每分钟接收的订单数）。监控系统能够提供一种早期故障告警系统，让开发团队跟进并调查。

这又无形中提升了对开发人员的技术要求！

扩展性

对于互联网产品来讲，这是个必选项！

之前在网上看到过一句话，大意是：「当你有一个想法的时候，世界上可能有1万我的也有这个想法！其中1000我的已经开始作了！100我的已经作完了！10我的已经运营了！1个已经盈利了！」

也就是说，相同的产品千千万。用户为什么就偏心你这款？

你的系统须要有核心竞争力，来吸引新用户！同时还须要不断的加入新功能，保持用户不流失！

可维护性

服务的数量增长了，维护的成本也就相应的增长了。除了上面提到的经过下降沟通成原本提升可维护性外，微服务还经过「基础设施自动化」来下降维护难度！

基础设施自动化有以下几个缘由：

• 因为微服务的服务较单体应用会多了不少，这就致使了部署微服务较部署单体应用来讲要复杂得多。单纯的靠运维来手动部署不现实
• 部署的服务较多，且是网状通讯，致使了一个请求可能会调用多个服务，对于请求的追踪不能像单体应用同样，靠日志来跟踪。须要追踪请求。
• 当请求异常时，或服务异常时，须要能自动的处理一些常见状况（也涉及上面的「容错性」）

参考资料

• Microservices
• Conway's Law – A Theoretical Basis for the Microservice Architecture
• 五分钟看懂韩都衣舍从20万到15亿的套路
• How Do Committees Invent