上周更新了一篇【揭秘】一个小团队真正能落地的微服务架构实践，很多网友私信询问在落地微服务的时候服务是如何拆分的？有没有具体的方法？可不可以一劳永逸？
额......好吧，针对大家比较关注的问题今天来分享一下之前在做电商的时候对公司产品做架构改造升级，以及跟其他同行一起聊过比较公认、适和小团队比较快速落地的微服务拆分方法。
备注：文章中提供的拆分方法不一定全部得到大家的认可，如果有更好的可以留言分享哦~~~
一、项目拆分背景
团队组成
UI设计：1人（其他专门做商品设计不算）
前端开发：2人
后端开发：5人（高、中、低搭配）
测试：2人
运维：由后端开发担任（你懂的......）
业务简介
和市场上大家经常用的的电商平台一样，用户可以通过PC端、APP和公众号H5等入口进入商城进行浏览商品、参加活动、下单、支付等业务，这里不做过多叙述！
系统模型
如下图所示：
5.pic.jpg
关注我们
二、设计拆分方案
1、基于业务逻辑拆分
遵从共同封闭原则，一个服务的开发和迭代不影响调用它API的消费端。特别是某个服务的改动会造成故障并影响其他服务。
将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务，保证各个服务能够独立运行就可以了。
是不是很直观？很简单？大家都知道的事情但是实际操作为啥会出现问题呢？
这种基于业务逻辑的拆分虽然很直观但是由于团队成员对于各自的职责范围理解差异很大，往往会出现意见向左的事情，很难达到统一。
例如：把上图的电商平台第一种方案拆分为“商品”、“订单”和“用户” 3个服务，这样看也能把整个业务囊括进去。但是看看第二种方案，如下图所示：
如下图所示：
拆分后
如图拆分为“商品”、“订单”、“用户”、“支付”、“广告”等6个服务，那么是不是更合理？那是否意味着拆分的越详细越好呢？
那就看一下“三个火枪手”原则！
2、服务拆分力度按照“三个火枪手”原则，1个微服务3个人负责开发。
就是说单纯的从业务逻辑角度拆分的话，很难判断服务的粒度。应该根据“三个火枪手”原则计算一下需要拆分的范围和数量，再确定合适的“职责范围”，避免出现拆分过粗或过细的情况。
并且3个人负责开发一个系统，系统的复杂度刚好达到每个人都能全面理解整个系统，又能够根据每个人的技术能力对开发任务进行合理分工。
这么分析来看这样的搭配非常完美，但是大家都懂的很少有人力资源很充足的情况出现，不然大家就不会集体抗议 996了。不管如何尽量避免出现一个人维护一个服务的情况出现，因为有两个方面的考虑，第一，微服务是相对封闭的，里面是一条垂直的线，需要有专人去跟踪。如果一个人维护有哪几点不好？第一是力度过细，第二个是万一这个人今天请假了或者是生病了，甚至离职了，那总要有一个人backup吧，避免出现系统性风险。
3、基于可扩展拆分
将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，常变化和迭代的服务拆分为变动服务。
例如：系统中的用户服务、订单服务等不经常变化，跟业务关系不大，但又是整个系统最基础的功能可以划分为稳定服务。系统中的广告服务、商品服务等经常变更和迭代的服务划分为变动服务。
记住针对团队人力资源不充裕的情况，稳定服务可以拆分粒度粗一点，甚至可以放到一个子系统中。当然经常变动的服务业不要太细，不然维护不过来，会导致各个环节都可能出现问题。
4、基于性能拆分
这个不难理解，基于性能拆分就是将性能要求高的或者会发生高并发业务场景的模块拆分出来，避免发生压力过大影响其他服务的正常使用。这里不细说，因为和具体的性能瓶颈有关，影响因素过多，例如：服务器、数据库、缓存、网络等等。典型的业务场景就是电商的秒杀抢购功能，可以独立成一个服务 相应的资源可以多倾斜。
大家可以参考这篇：高并发服务器逻辑处理瓶颈，如何解决？
5、基于基础设施拆分
基础设施通常大家都忘记了吧，并且安排工作量的时候 很少写进工时里面的吧？领导也是看不见的工作量吧？但是可以说真正决定微服务成败的，恰恰是那个被大部分人都忽略的。系统落地后麻烦不断，简直就是坑中之坑，基础设施的建设也是考验整个团队的核心环节！
来看一下微服务的基础实施需要掌握哪些知识：
微服务的基础设施
额。。。是不是懵了？这个小团队玩不转吧？！把这些搞完估计项目都黄了，哈哈哈！
虽然建设完善的微服务基础设施是一项庞大的工程，但是也不用看完后就放弃，或者认为自己是个小团队就不使用微服务了。虽然看起来很多但是目前市场上已经有成熟的开源框架直接拿来用的微服务基础设施。例如：SpringCloud，里面集成了服务发现、服务路由、网关、配置中心等常用的功能。再说了上面那么多基础设施并不是每个都是必须的，来来来我们划分个优先级：
1、服务发现、服务路由、服务容错：这是最基本的微服务基础设施。
2、接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率。
3、自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率。
4、服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率。
根据优先级分析来看3和4两种是随着微服务节点数量的增加而越来越重要，前期拆分的服务较少并且团队对于微服务架构也在逐渐掌握中，可以暂时采用人工的方式，虽然效率低了点，但是不会因为某个环节熟悉程度不够而导致整体崩盘的情况。
三、经验总结
最后放上一张最终完成的系统访问交互流程图：
系统访问交互流程图
最后也写一下自己用微服务拆分改造后的一些经验吧，前期根据上面的拆分法则做架构改造还是比较舒服的，这里是真的舒服！因为业务更、代码、规范更清晰了，每个人的职责也更加明确了，特别是团队开发热情和积极性非常的高。因为从规划到落地的过程大家都成长了许多。但是这些还远远不够，由于职责、代码明确到个人，这样对于团队成员的学习能力也是很大的挑战。就拿学习能力来说吧，单体架构的时候可能只需要把自己开发的接口写好暴露出来就行了，但是微服务是从前到后的相关知识都需要学习，整体体系还是非常庞大的。
总之，微服务架构不再是一个人打天下的时代了，而是通过整个团队的技术综合水平来衡量了。发完搞 估计又有许多人私信说 只是理论罢了 没有一点实用价值，其实我也明白 现在很多人想要的就是 直接把源码地址贴出来就行了，直接down下来用。这里只想说洗洗睡吧！。
关注我们
优质文章推荐
贡献者
更多精彩内容可以关注“IT实战联盟”公众号哦~~~
image
网友评论