知其然，知其所以然。
微服务大行其道之时，不少有识之士大声疾呼“致传统企业朋友：不够痛就别微服务，有坑”，“能不能拆分服务就不拆分”，但仍然无法阻挡对于微服务实施的热情和向往。
一则，开源全家桶用了之后，找工作方便一点。
二则，“上面领导”让用的，我们coding发现写代码测试麻烦了，我们无能为力。
本文仅仅探讨一下你选择什么，获得什么，承受什么。如果没有做好评估，则“得无所得”，可能陷入一地鸡毛的泥潭。
为什么要做服务化？
笔者习惯把单体架构和服务化架构作为对照，“微服务” 在微上面容易陷入争议和费解。
一位朋友说他觉得公司很折腾。
“几个开发，微服务数量有30个之多，数据访问DAO层和应用逻辑层也是独立的进程，写代码麻烦”！
克里斯·理查森在《微服务架构设计模式》一书中，对于单体架构和微服务做了一个对比，笔者用表格表达如下：
从表格可以看到，微服务架构并不是代表领先，而是取决于应用的复杂度，越复杂，单体架构铁板一块（同频研发、同频发布）遭遇的挑战越大，而微服务架构越有优势。
结论：
1、服务化架构（微服务）更适合复杂领域的应用系统。
2、服务化架构（微服务）并不代表业务交付效率更高。
对于这2个结论的细节，后面酌情补充。
业务高速发展的早期形态1:臃肿单体架构
潘志伟老师曾经总结在传统的软件开发中遇到下面的“痛”，标志着应该从单体架构走向服务化架构：
1、代码冲突加剧
多个人或者一个团队一起维护一个模块，共同开发。当提交代码的时候发现大量冲突，每次提测或者发版的时候需要花大量的时间来解决冲突。随着团队规模的增大以及项目复杂程度增加，代码冲突的现象越严重；
2、模块耦合严重
模块之间通过接口或者DB相互依赖，耦合越来越严重。而且不同的人，写代码的风格不一样，代码质量也不一样，上线前需要协调多个团队，任何小模块的异常都会导致整个项目发布失败；
3、项目质量下降
由于所有的代码都是在一个服务里面，做一次改动，可能会牵一发而动全身，代码冲突以及耦合严重，导致测试覆盖范围不充分，经常会出现没有更改的模块在线上突然出现问题，查询后发现是由于工程师不小心做了某种改动，但是测试用例并没有覆盖；
4、团队效率下降
由于大量时间在处理代码冲突，消耗了研发人员大量的时间；而测试人员为了提高项目质量，不得不在每次发版之前做全方位的回归测试，本身一次小的迭代结果项目时间却很长。
业务高速发展的早期形态2:烟囱型架构
以头哥分享的传统金融的架构演进为例，烟囱型架构并不代表不能支持业务。甚至应对业务的效率不低。比如发展一块新业务，就有一个团队去支持，没有人甩锅，大家all-in。
随着业务规模发展到，人员的增长不能按照线性增长去满足业务的时候，问题就凸显出来。
一般存在几个问题。
1、功能的复用问题，大家都在修改用户服务，能不能一个全功能团队维护，更快一点。当然，我们先假设这样是美好的。
2、人员能力问题，涉及到中间件，大家想用什么用什么，各团队的TL和架构师存在感都很强，但存在搞不定的情况， 如果出故障多了，老板就火大了。
还有其它问题，老王总结为下面几个方面：
