概述
现在被谈论最多的就是微服务和中台系统，我个人的理解是微服务或者是中台好不好，主要看实际的业务场景，架构的变迁往往需要耗费很大的学习成本和时间成本，所以更改架构的时候要三思而后行，适合自己特别重要。
由单体到多应用的演变
从我入职开始，公司已经从单体走向了垂直拆分，比如单库查询，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
- 第二定律：时间再多一件事情也不可能做的完美，但总有时间做完一件事情。
- 第三定律：线型系统和线型组织架构间具有潜在的异质同态特种
- 第四定律：大的系统组织总是比小系统更倾向于分解
其他原则：
- 人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分来达成对沟通效率的管理。
- 组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计
- 如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更加合理高效
- 复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的
