面试官如果看到这里，经常会问这样的一个面试问题：你在微服务拆分这件事情上有哪些心得，可以讲一讲吗？
此时，如果候选人没有提前思考储备这个问题，往往会被问得语无伦次，毫无章法地瞎答一气。
我见过最离谱的答案是，候选人说他微服务拆分的心得是——微服务拆得越细越好，必须突出一个“微”字。
不要怕，学长都已经梳理好了，接下来我们就来看看，微服务拆分有哪些心得和经验之谈。
图片
拆分方案
上图中列举的这四种拆分方案，其中并没有优劣好坏之分，每种拆分方案都有其适用的业务场景。
1、基于业务领域
这是一种最为常见的拆分方案，我们以电商场景进行举例，可以将一个大单体架构的电商系统，拆分为包含API网关、用户服务、商家服务、客服服务、商品服务、订单服务、物流服务、促销服务和结算服务的微服务架构的电商系统。
如下图所示，拆分前：
图片
拆分后：
图片
2、基于变化频率
小到系统代码中的类和方法，大到系统的模块或服务，我们都可以将系统中经常变化的部分和变化频率很低的部分进行分离。
分离变与不变的意义是，研发人员可以在整个DevOps周期中，更加聚焦地关注经常变化的服务的可维护性、可扩展性，最终起到提升研发效率的效果。
此外，我们可以把经常变化的服务的粒度拆分得细一些，因为它会随着日常需求的不断迭代而逐步变大，避免以后进行二次拆分。反之，变化频率很低的稳定态服务的粒度拆分得粗一些，减少分布式系统的链路复杂度和运维困难度。
3、基于重要等级
这种拆分方案的做法是，将重要等级高的业务模块与重要等级较低的业务模块进行拆分，使其形成各自的服务，旨在通过链路隔离的方式减少后者对于前者的影响，提升系统核心链路的可用性。
当然，除了应用服务器之外，两者在中间件和数据库服务器上也要各用各的，这样才能起到彻底隔离的效果。
我们还是以电商场景进行举例，如下图所示：
图片
另外，基于重要等级进行系统拆分，是一项极其耗时且复杂的工作，研发团队在考虑此策略时，一定要衡量好ROI（投入产出比）。
个人建议，如果是一天都没多少业务量的创新业务或边缘业务，那就免了吧。
4、基于并发度
这种拆分方式，是将系统中并发度明显很高的业务模块单独拆分出来，旨在以专人专事专用服务的方式更好地解决问题。
举个例子，IPhone单品秒杀和正常业务场景下的订单服务，由于其并发度不同，在架构方案、存储设计和硬件资源配置上，思路也是完全不一样的。那么，将两者进行微服务拆分，可以使其更加聚焦地解决各自业务场景的问题。
再举一个在线教育约课场景的例子，公司存在这样的一个业务场景，每周五中午12点开放预约下周的课程。那么，系统百万用户中的大部分人都去抢着预约心仪老师的课程。
此时，约课系统需要承担的请求压力极大，尤其是最为核心的“预约课程”接口，每周五中午12点到12点10分期间的TPS甚至可以达到万级别。
因此，在我们进行系统改造优化之前，在 “每周五中午12点到12点10分” 这个时间段内，经常会出现系统扛不住请求流量而导致宕机的情况出现。
在这种瞬时流量洪峰的情况下，可以通过MQ消峰的方式解决。我们需要做的是将“约课前置服务”从“约课服务”中拆分出来，把用户的约课请求中的参数进行前置校验后，将请求信息发送给Kafka Broker。
如下图所示：
图片
拆分粒度
对于微服务的理解，Martin Fowler曾经说过这样一段话：
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.
有些同学看到了small services这两个单词，就认为微服务的拆分粒度越小越好，其实并不是这样的。
粒度过小的微服务不仅会增加硬件成本，同时也会过度消耗团队的DevOps成本，在这里大家不妨了解一下三个火枪手原则。
三个火枪手原则意思是，一个微服务拆分的粒度，最好可以容纳三个工程师同时对其进行开发。
从团队的角度上，三个工程师可以形成很好的互备；从系统的角度上，三个工程师开发维护的系统，复杂度不会太高，也很难由于代码冲突而导致互相影响。因此，三个火枪手原则算是从多个角度平衡后的最优解吧。
当然，这里面说的“三个”工程师只是一个参考意见，并不是完全一成不变的，可根据公司研发团队的实际情况进行上下浮动。
拆分标准
再列举几个微服务拆分的标准吧，这个并不需要完全对标，只需要尽量往这个方向上靠即可。
1、单一职责原则
以上文中的电商场景进行微服务拆分为例，每个微服务尽量做到只负责一个业务领域，这样可以使其职责更加清晰。
2、服务自治原则
每个微服务都需要做到高度自治，可以进行独立开发、独立测试、独立部署和独立运行，尽量减少对其他服务的强依赖，这样能够降低团队间的沟通成本。
3、可观察性原则
每个微服务都可以通过监控系统、日志系统和链路追踪系统观察到其运行状态、性能指标和业务处理情况。
4、可复用性原则
每个微服务都应该对外提供通用的能力，可以为其他的多个服务复用，这样可以提升研发效率。
