概述

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

(资料图片仅供参考)

由单体到多应用的演变

从我入职开始，公司已经从单体走向了垂直拆分，比如单库查询，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第二定律：时间再多一件事情也不可能做的完美，但总有时间做完一件事情。第三定律：线型系统和线型组织架构间具有潜在的异质同态特种第四定律：大的系统组织总是比小系统更倾向于分解

其他原则：

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