概述
现在被谈论最多的便是微服务和中台体系，我个人的了解是微服务或者是中台好不好，主要看实际的事务场景，架构的变迁往往需求耗费很大的学习本钱和时刻本钱，所以更改架构的时分要三思而后行，合适自己特别重要。
由单体到多使用的演化
从我入职开端，公司现已从单体走向了笔直拆分，比方单库查询，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 - 第二规律：时刻再多一件工作也不或许做的完美，但总有时刻做完一件工作。
- 第三规律：线型体系和线型安排架构间具有潜在的异质同态特种
- 第四规律：大的体系安排总是比小体系更倾向于分解
其他准则：
- 人与人的交流是非常杂乱的，一个人的交流精力是有限的，所以当问题太杂乱需求许多人处理的时分，咱们需求做拆分来达成对交流效率的办理。
- 安排内助与人的交流方法决议了他们参加的体系规划，办理者能够经过不同的拆分方法带来不同的团队间交流方法，然后影响体系规划
- 如果子体系是内聚的，和外部的交流边界是清晰的，能降低交流本钱，对应的规划也会愈加合理高效
- 杂乱的体系需求经过容错弹性的方法继续优化，不要盼望一个大而全的规划或架构，好的架构和规划都是渐渐迭代出来的
