简单说两句微服务拆分

上周六参加了魔窗组织的一个线上跨境茶话会Live的交流活动，主题是《微服务的挑战》，虽然另外两位嘉宾和我的背景各不相同，所在的企业的业务也完全不一样，但是聊到后面，大家的观点还是基本一致的。针对里面的环节，选取了“微服务拆分”这个小议题，做了一个小结，谈谈个人的一点看法。

首先从基本原则看，我们拆分出来的服务需要实现一个强相关的方法的小集合，服务必须遵从共同封闭原则，一个服务的实现的更新和迭代不影响调用它API的消费端。

一个服务可以被3-5人规模的小团队开发。每个人公司的情况不一样，如果我们不考虑人的资源的情况下，我觉得一般是三个人就足够了。因为有两个方面的考虑，第一，微服务是相对封闭的，里面是一条垂直的线，需要有专人去跟踪。如果一个人维护有哪几点不好？第一是力度过细，第二个是万一这个人今天请假了或者是生病了，甚至离职了，那总要有一个人backup吧，避免出现系统性风险。

每个团队应该是自主的，一个团队可以自主开发和部署他们的服务。电商也好，互金领域也好，基本的方式就是根据业务能力来拆分。比如订单、客户管理、产品，我们都是按照这种方式来拆。但是实际上在业务维度之外我们还有一个领域概念，我们会把服务划为三块：

第一块是基础服务，它其实是跟业务关系并不大，但是能提供系统最基础的功能，比如用户、订单，或者叫通用服务。

第二块是支持服务，比如第三方的一些东西，比如发短信、支付网关，可能跟我直接业务没有关系了，但是是对我的业务有一定支持作用。

第三块就是核心业务了，核心业务比如我的审批流程，或者是风控，这是我的核心价值，那是一块。我基本上是从这两个角度来看，一个是业务，另一个就是领域。

 最后说一点，微服务拆分后，很重要的一点就是团队工程师能力的提升，自我的驱动力必须要更高，因为工程师要对这个服务负责，需要深入了解业务的情况。第二个就是学习能力要更强，由于从前到后的相关知识都需要学习，不是说把接口暴露出来做好就可以了。对服务负责的要求，就是技术、业务你都要服务。当然反过来说，对于工程师个人的成长也打开了更大的空间。    

团队发展到一定阶段，会有一个架构师的角色或者是技术经理的角色，整个团队相当于变成了一个球队，架构师和技术经理对应于球队教练的角色。作为主教练需要考虑这个球队如何保持一个整体，一个球队，分成中场、前端或者是后卫，怎么保持他们的阵型，中间的配合是不是足够到位，传球顺不顺，中场和前场会不会脱节等等，这都是技术管理者要解决的问题。 

后续会有本次线上LIVE的完整版发布出来，到时候分享给大家，欢迎更多朋友一起讨论。

扫描二维码或手动搜索微信公众号【架构栈】： ForestNotes

欢迎转载，带上以下二维码即可

                          

点击“阅读原文”，所有【架构栈】近期的架构文章汇总