微服务 - 拆分微服务的问题和拆分方法

概述

现在被谈论最多的就是微服务和中台系统，我个人的理解是微服务或者是中台好不好，主要看实际的业务场景，架构的变迁往往需要耗费很大的学习成本和时间成本，所以更改架构的时候要三思而后行，适合自己特别重要。

由单体到多应用的演变

从我入职开始，公司已经从单体走向了垂直拆分，比如单库查询，Redis、Es、MongoDB已经在系统中广泛应用，中途也遇到了些调用混乱的问题，我们在之前的MVC中加入了一个Service层做了一次数据聚合层，并且一直良好运行了很久，峰值请求大概在百万级左右，在寒暑假的时候会稍微多一点。

在开始微服务之前其实我心里有自己的方案，团队比较小，其实没有必要进行微服务的拆分，如果非要拆分在原基础上把yaf换成Swoole模式的，就能得到性能和成本之间的平衡，但是没有得到采纳，其实略有遗憾，在团队里没有话语权，是一件没有办法能解决的问题。

在这里多说一句，微服务并不是解决高并发的问题，微服务是一种架构思想，再了解微服务的过程中，也走了不少弯路，网上有很多Java实现的微服务，Go语言的，Rust的，甚至还有python的，其实单纯从语言层面来说，语言的性能正在缩小，技术人要有自己的思考，不能麻木跟风。

拆分微服务遇到的问题

微服务我就不说了，在这里写写那些设计的要素和一定能遇到的坑。

比如我们的业务是阅读App，里面的核心是作品，但是作品的详情页会集中展示评论、用户、章节需要的数据信息，之前都同一个Service层，这是第一个需要思考的问题。

拆分颗粒度：拆分微服务最难的点在于怎么把握服务于服务之间的颗粒度，这个很难把握，如果拆大了，只是改了个名字，换汤不换药，拆小了聚合数据又会存在问题，这中间的过程真是让人抓狂。

下面我说说当时遇到的问题，拆分的日子真是让人抓狂：

1.服务划分过细，服务关系复杂，服务划分过细，单个复杂度就会下降，但是整个系统的复杂度就会上升上来，因为微服务把系统内的复杂度转移为了系统间的复杂度。

2.服务数量太多，团队效率急剧下降，这里的误区是微字就意味着拆分的很细。

3.没有自动化支撑，无法快读交付，现在极客时间里有GitOps，可以看这个，写的很好。

4.没有服务治理，微服务达到一定数量，后台管理混乱。

5.以前一条sql搞定的事情，现在需要从多个服务里获取，在一定程度上提升了开发难度。

拆分微服务方法梳理

从网上梳理了一些拆分微服务的方法论，希望对你有一些参考的价值：

1.纵向拆分和横向拆分

• 从业务维度进行拆分，标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分成一个微服务，而功能相对比较独立的业务适合拆分为一个微服务。
• 从公共且独立功能维度拆分，标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不与其他业务耦合。

2.拆分微服务还是综合考虑的因素

• 业务逻辑
• 基础设施建设(自动化测试、自动化部署、服务监控，服务发现、配置中心等等)，决定成败的往往是基础设施建设，和业务无关。
• 将系统中的模块按照稳定性来划分，将已经成熟的和改动不大的归类为稳定的服务。

3.按照业务颗粒度划分，分出了2种可能。

• 按照粗颗粒度划分：作品、用户、评论、消息
• 按照细颗粒度：作品、用户、有声、评论、动态、客服IM、综合等等就很多很多了。

拆分原则

3个火枪手原则：一个微服务由三个人开发，在进行微服务架构时，根据团队规模来划分数量也是合理的。

AFK拆分原则：

• X轴，水平复制，多加载几个应用实例，以集群加负载均衡的模式进行拆分
• Y轴，微服务经常采用的按业务逻辑划分
• Z轴，按照数据进行划分

康威定律

• 第一定律：组织沟通方式会通过系统设计表达出来，人月神话中总结出了随着人员的增加沟通成本呈指数增长的规律，沟通成本n(n-1)/2
• 第二定律：时间再多一件事情也不可能做的完美，但总有时间做完一件事情。
• 第三定律：线型系统和线型组织架构间具有潜在的异质同态特种
• 第四定律：大的系统组织总是比小系统更倾向于分解

其他原则：

• 人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分来达成对沟通效率的管理。
• 组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计
• 如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更加合理高效
• 复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的