下载掌阅APP，畅读海量书库
立即打开
微服务：你有病啊？
传统架构：你有药啊？
微服务：你吃多少？
传统架构：你有多少我吃多少。
面对传统应用的大部分病症，微服务的存在如同一剂良药，让大家看到了希望。
很多人都会犯讳疾忌医的错误，在病情轻微时忽视，进而引起更严重的病变，最终无药可救。
“君有疾在腠理，不治将恐深。”这是一个关于时机的问题，趁早治疗还有的救，因为治疗是要考虑很多因素的。微服务虽然可以解决传统应用的大部分问题，但是它终究是一个工具，无法起死回生。
传统应用的痛就像牙疼，虽然明知早治早好，但是就是下不了决心，觉得还可以忍受，最终发现还是忍不了，然后去拔牙，悔不如当初早点治疗。
这是一个单向不可逆的过程，最终结果就是传统应用实在挺不住了，花重金重新来做。
要有合适的人在合适的时间通过使用微服务，对传统应用进行治疗才行。
最佳治疗时机是当还有人对业务和技术架构熟悉的时候。如果已经没有人熟悉系统，那么要多花大量的精力和时间来熟悉系统才能下手。
传统架构或多或少都会有一些问题，如果及时治疗，成本和代价都会比较小。随着时间的推移，越往后越难治，晚期就是“植物人”。
一个系统经数人之手开发了数年，现在要重构，可能重构的成本比重新做一个的成本还要高。
因为随着核心人员的流失，懂业务和对系统熟悉的人越来越少，如果没有一个很好的知识库体系，那么新来的人对系统的了解只会越来越少，越来越片面。
这时即使投入巨大的人力和时间，最后不一定能治好，只能是死马当活马医。
好的架构是什么样的？
幸福的家庭都是一样的，不幸的家庭各有各的不幸。
这个说法用在架构上也一样。
当初设计合理的架构不一定满足未来的需要，当初设计不合理的架构则注定上演悲剧。
国内很多系统都是紧急上线，短期内用“人肉”堆出来的，埋下了很多隐患，挖了很多坑，领导不管那些，先上线再说，还得用这个当成功案例做推广呢，底下的人也跟打了鸡血一样拼了老命把系统给上线了。
结果就是苦了后来的“接码侠”，谁接谁知道。
好的架构就是一开始就要考虑后面的扩展和修改。
据说以前配毒药的时候，要先把解药配出来，这是为了防止自己中毒“扑街”。
这就像《富士山下》里唱的，“要拥有必先懂失去怎接受”。
好的架构应该是解耦的，如果修改一个地方，不影响其他地方，不需要从前台到后台的联动。如果一个功能要修改就会涉及从前台到后台的一系列改动，那就说明系统耦合严重。
好的架构一定是轻量灵活的。
船小好掉头，可以应对千变万化的业务需求。不会像传统应用那样本身架构对新业务的支持不好，只能让业务和功能互相妥协，勉强把新业务功能加上去。这种妥协是对双方的伤害，既破坏了原有架构，又埋下了隐患。
传统应用的病不是简单打一针就能看到疗效的，所以论证的过程就显得十分重要。论证可以通过沙盘演练的方式来实现，看看使用微服务之后到底灵不灵。
➢ 公输班和墨子
战国时，宋国面对强大的楚国的威胁，无计可施，随时可能崩溃，这时候墨子来了，和公输班进行了一场沙盘演练，面对各种攻城方法，墨子一一化解。
先不说实战如何，起码理论上要行得通。
那么是否引入微服务也要进行这么一场沙盘推演，现在系统的问题是否可以通过微服务就能够解决。
比如用具体的需求来说明，之前的一个需求涉及修改代码的地方是多少处，工作量是多少，测试的工作量又是多少，交付周期是多久。现在采用微服务之后，有哪些变化，开发工作量和测试工作量减少多少，交付周期、人员数量等都是可以量化的指标。
比如，新增业务、需求变更，微服务如何应对？
一方攻城，一方守城，微服务就是守城的一方，面对各种需求，如何化解，同时与当前系统的区别是什么，有哪些方面的提升？
传统应用“以不变应万变”，结果就是什么都得吃不了兜着走。因为本身没有变化的技能点，属于先天缺陷。
微服务“以万变应万变”，就如同《西游记》中孙悟空与二郎神之间的斗法，优势就是可以进行各种变化、扩展，全是技能点。可以通过自身的变化应对系统可能的各种变化，并保持系统的一个稳定健康的状态，不会像传统应用一样，为了应对业务的变化不得不破坏自身架构的一致性。
就像一个哲人曾经说过：如何你不能阻止环境的变化，那么就改变自己去适应它吧。
微服务架构可以轻松应对需求的变化，从而达到快速交付的目的。
通过采用沙盘演练的方式可以很直观地论证微服务架构是否可以应对复杂变化，解决实际问题，是否可以根除传统应用固有的顽疾。