无人自助超市
微服务是近⼏年⾮常⽕热的架构设计理念，我们需要正确理解微服务，否则如果只是跟风拿来就⽤，既不会⽤，也⽤不好，⽤了不但没有效果，反⽽还可能有副作⽤。
今天我们就来深⼊理解微服务，如何避开陷阱，设计⼀个成功的微服务架构
⼀. 微服务缺陷
锅炉烟囱制造服务划分过细，单个服务的复杂度确实下降了，但整个系统的复杂度却上升了，因为微服务将系统内的复杂度转移为系统间的复杂度了。从理论的⾓度来计算，n 个服务的复杂度是 n×(n-1)/2，整体系统的复杂度是随着微服务数量的增加呈指数级增加的。下图形象了说明了整体复杂度： 服务粒度图
粗粒度划分服务时，系统被划分为 3 个服务，虽然单个服务较⼤，但服务间的关系很简单；细粒度划分服务时，虽然单个服务⼩了⼀些，但服务间的关系却复杂了很多。
2. 服务数量太多，团队效率急剧下降
微服务的“微”字，本⾝就是⼀个陷阱，很多团队看到“微”字后，就想到必须将服务拆分得很细，有的团队⼈员规模是 5~6 个⼈，然⽽却拆分出 30 多个微服务，平均每个⼈要维护 5 个以上的微服务。 3. 服务调⽤链太长，性能下降
由于微服务之间都是通过 HTTP 或者 RPC 调⽤的，每次调⽤必须经过⽹络。⼀般线上的业务接⼝之间的调⽤，平均响应时间⼤约为 50 毫秒，如果⽤户的⼀起请求需要经过 6 次微服务调⽤，则性能消耗就是 300 毫秒，这在很多⾼性能业务场景下是难以满⾜需求的。 4. 没有⾃动化吃撑，⽆法快速交付
如果没有相应的⾃动化系统进⾏⽀撑，都是靠⼈⼯去操作，那么微服务不但达不到快速交付的⽬的，甚⾄还不如⼀个⼤⽽全的系统效率⾼。
5.没有服务治理，微服务达到⼀定数量，后台管理混乱
信奉微服务理念的设计⼈员总是强调微服务的 lightweight 特性，并举出 ESB 的反例来证明微服务的优越之处。但具体实践后就会发现，随着微服务种类和数量越来越多，如果没有服务治理系统进⾏⽀撑，微服务提倡的 lightweight 就会变成问题。
⼆.微服务最佳实践
针对微服务拆分过细导致的问题，我建议基于团队规模进⾏拆分。我认为微服务拆分粒度的“三个⽕⼿”原则，即 1 个微服务 3 个⼈负责开发。
3 个⼈负责开发⼀个系统，系统的复杂度刚好达到每个⼈都能全⾯理解整个系统，⼜能够进⾏分⼯的粒度。
从团队管理来说，3 个⼈可以形成⼀个稳定的备份，即使 1 个⼈休假或者调配到其他系统，剩余 2 个⼈还可以⽀撑。
从技术提升的⾓度来讲，3 个⼈的技术⼩组既能够形成有效的讨论，⼜能够快速达成⼀致意见。
“三个⽕⼿”的原则主要应⽤于微服务设计和开发阶段，如果微服务经过⼀段时间发展后已经⽐较稳
定，处于维护期了，⽆须太多的开发，那么平均 1 个⼈维护 1 个微服务甚⾄⼏个微服务都可以。当然考虑到⼈员备份问题，每个微服务最好都安排 2 个⼈维护，每个⼈都可以维护多个微服务。
三.拆分⽅法
基于“三个⽕⼿”的理论，我们可以计算出拆分后合适的服务数量。根据⽬的的不同灵活地选取不同的拆分⽅式。接下来我⼀⼀介绍常见的拆分⽅式。
1.基于业务逻辑拆分
这是最常见的⼀种拆分⽅式，将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为⼀个独⽴的服务。
基于业务逻辑拆分虽然看起来很直观，但在实践过程中最常见的⼀个问题就是团队成员对于“职责范围”的理解差异很⼤，经常会出现争论，难以达成⼀致意见。例如：假设我们做⼀个电商系统，第⼀种⽅式是将服务划分为“商品”“交易”“⽤户”3 个服务，第⼆种⽅式是划分为“商品”“订单”“⽀付”“发货”“买家”“卖家”6 个服务，哪种⽅式更合理，是不是划分越细越正确？
导致这种困惑的主要根因在于从业务的⾓度来拆分的话，规模粗和规模细都没有问题，因为拆分基础都是业务逻辑，要判断拆分粒度，不能从业务逻辑⾓度，⽽要根据前⾯介绍的“三个⽕⼿”的原则，
计算⼀下⼤概的服务数量范围，然后再确定合适的“职责范围”，否则就可能出现划分过粗或者过细的情况，⽽且⼤部分情况下会出现过细的情况。
例如：如果团队规模是 10 个⼈⽀撑业务，按照“三个⽕⼿”规则计算，⼤约需要划分为 4 个服务，那么“登录、注册、⽤户信息管理”都可以划到“⽤户服务”职责范围内；如果团队规模是 100 ⼈⽀撑业务，服务数量可以达到 40 个，那么“⽤户登录“就是⼀个服务了；如果团队规模达到 1000 ⼈⽀撑业务，那“⽤户连接管理”可能就是⼀个独⽴的服务了。
2.基于可扩展拆分
将系统中的业务模块按照稳定性排序，将已经成熟和改动不⼤的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。稳定的服务粒度可以粗⼀些，即使逻辑上没有强关联的服务，也可以放在同⼀个⼦系统中，例如将“⽇志服务”和“升级服务”放在同⼀个⼦系统中；不稳定的服务粒度可以细⼀些，但也不要太细，始终记住要控制服务的总数量。
这样拆分主要是为了提升项⽬快速迭代的效率，避免在开发的时候，不⼩⼼影响了已有的成熟功能导致线上问题。
3. 基于可靠性拆分
将系统中的业务模块按照优先级排序，将可靠性要求⾼的核⼼服务和可靠性要求低的⾮核⼼服务拆分开来，然后重点保证核⼼服务的⾼可⽤。具体拆分的时候，核⼼服务可以是⼀个也可以是多个，只要最终的服务数量满⾜“三个⽕⼿”的原则就可以。
这样拆分带来下⾯⼏个好处：
避免⾮核⼼服务故障影响核⼼服务
核⼼服务⾼可⽤⽅案可以更简单
能够降低⾼可⽤成本
4.基于性能拆分
基于性能拆分和基于可靠性拆分类似，将性能要求⾼或者性能压⼒⼤的模块拆分出来，避免性能压⼒⼤的服务影响其他服务。常见的拆分⽅式和具体的性能瓶颈有关，可以拆分 Web 服务、数据库、缓存等。例如电商的抢购，性能压⼒最⼤的是⼊⼝的排队功能，可以将排队功能独⽴为⼀个服务。
以上⼏种拆分⽅式不是多选⼀，⽽是可以根据实际情况⾃由排列组合，例如可以基于可靠性拆分出服务 A，基于性能拆分出服务 B，基于可扩展拆分出 C/D/F 三个服务，加上原有的服务 X，最后总共拆分出 6 个服务（A/B/C/D/F/X）。定时点火装置
四.基础设施
碳氟化钾
⼤部分⼈主要关注的是微服务的“small”和“lightweight”特性，但实际上真正决定微服务成败的，恰恰是那个被⼤部分⼈都忽略
的“automated”。为何这样说呢？因为服务粒度即使划分不合理，实际落地后如果团队遇到⿇烦，⾃然会想到拆服务或者合服务；如
果“automated”相关的基础设施不健全，那微服务就是焦油坑。
微服务基础设施图
拟合直线看到上⾯这张图，相信很多⼈都会倒吸⼀⼝凉⽓，说好的微服务的“轻量级”呢？都这么多基础设施还好意思说⾃⼰是“轻量级”，感觉⽐ESB 还要复杂啊？
确实如此，微服务并不是很多⼈认为的那样⼜简单⼜轻量级。要做好微服务，这些基础设施都是必不可少的，否则微服务就会变成⼀个焦油坑，让业务和团队在⾥⾯不断挣扎且⽆法⾃拔。因此也可以说，微服务并没有减少复杂度，⽽只是将复杂度从 ESB 转移到了基础设施。你可以看到，“服务发现”“服务路由”等其实都是 ESB 的功能，只是在微服务中剥离出来成了独⽴的基础系统。
虽然建设完善的微服务基础设施是⼀项庞⼤的⼯程，但也不⽤太过灰⼼，认为⾃⼰团队⼩或者公司规模不⼤就不能实施微服务了。第⼀个原因是已经有开源的微服务基础设施全家桶了，例如⼤名⿍⿍的 Spring Cloud 项⽬，涵盖了服务发现、服务路由、⽹关、配置中⼼等功能；第⼆个原因是如果微服务的数量并不是很多的话，并不是每个基础设施都是必须的。通常情况下，我建议按照下⾯优先级来搭建基础设施：
1. 服务发现、服务路由、服务容错：这是最基本的微服务基础设施。
2. 接⼝框架、API ⽹关：主要是为了提升开发效率，接⼝框架是提升内部服务的开发效率，API ⽹关是为了提升与外部服务对接的效
率。
3. ⾃动化部署、⾃动化测试、配置中⼼：主要是为了提升测试和运维效率。
4. 服务监控、服务跟踪、服务安全：主要是为了进⼀步提升运维效率。古代蹴鞠用什么做的
以上 3 和 4 两类基础设施，其重要性会随着微服务节点数量增加⽽越来越重要，但在微服务节点数量较少的时候，可以通过⼈⼯的⽅式⽀
撑，虽然效率不⾼，但也基本能够顶住。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议