微服务是如何来的

最近不太忙了，把关于微服务的一些想法整理一下。

编码的时候都会说起KISS原则，随着软件规模的扩大，业务的复杂，想保持这一原则就变成了一种挑战。古语话说天下，合久必分，分久必合……软件从一开始可能更多的考虑就是如何尽量的压榨一CPU和内存，尽量在主机数量有限的情况下，不增加复杂性的前提下完成。但是时代在变化，摩尔定律也在极速的方式改变着程序的运行环境。

这时候发现巨大的单体应用，反而不太适合了。一个管理端，其中可能有些核心的业务逻辑，从上线以后就不会改变。另外一些报表可能时不时就要改一下的。这个时候，如果还是在一个单体应用中，那么你最会面对一个问题，你改的这个报表会影响那个核心业务么？实际不可能的，这两个从代码上根本没关联的吧。但是真的仔细考虑，又没有可能合并版本的时候合才了，发版本的时候搞错了呢？最终在压力下，你也只能说大概不可能吧。最终不行就加测试吧。本来一天研发测试就能解决的问题，变成了漫长的一周……

想用别的系统的一个数据，这个时候你会觉得最远的举例不是网通和电信，有可能就是同一机房里面的两个应用。

这里面要说的一点是其实之前的单体应用的时候，为了解决这些问题，其实也想过很多办法的。也某种程度上解决了这些问题。比方通过模块化，插件化，通过各种协议土法来实现不同系统之间的数据通讯。但是这种实现对整体的要求更多一些。淘宝早期，各种BBS早期也都是经历过这样的阶段。

随着上面的摸索，应用逐渐的变成了服务。

这个过程中Amazon是SOA的坚定贯彻者，把应用服务化，把各种数据通讯改早成统一的数据服务。这个过程中服务开始出现，系统之间的壁垒也逐渐打破了。各种工具链,方法论也在这个过程中产生了。服务的数量，服务器的数量都开始急聚的增加。服务化涉及的一些方法论CAP,大数据之类的都开始构建起来。

随着服务化深入人心以后，那么剩下的问题就拆迁了。为什么不能再细化呢？这样可以以更小的粒度来控制。拆分以后，服务之间的比例不一定是1:1了。有可能是1:1000。扩容的时候也更容易了，避免了资源的浪费。随着Docker的出现。这种想法更有了可以快速落地的可能性。之前你要实现这些东西，你需要厉害的程序员，厉害的运维，厉害的体系建设等等。现在忽然发现这些都不需要了…… 这其中微服务也逐渐形成了自己的方法论The Twelve Factors.把这些简单的规则吃透了，比什么都强。

这时候可能看看之前的Unix操作系统，感觉两者挺像的

• 小即是美（Small is beautiful）
• 让程序只做好一件事（Make each program do one thing well）
• 尽可能早地建立原型（Build a prototype as soon as possible）
• 可移植性比效率更重要（Choose portability over efficiency）
• 尽可能地榨取软件的全部价值 Use software leverage to your advantage.

这时候好像微服务成了水到渠成的事情了。但是事情又像一个极端走去了。开发个东西，不服务化好像就不行了……必须把服务的数量搞上去，为了微服务而服务化。微服务追求的无外乎快速迭代，快速扩容。如果没这两点需求，或者需求不明显的话，那么不用微服务也能满足你。

下次讲划分微服务。