微服务是如何来的

2020-06-27 • 3 minutes to read

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

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

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

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

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

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

这个过程中AmazonSOA的坚定贯彻者,把应用服务化,把各种数据通讯改早成统一的数据服务。这个过程中服务开始出现,系统之间的壁垒也逐渐打破了。各种工具链,方法论也在这个过程中产生了。服务的数量,服务器的数量都开始急聚的增加。服务化涉及的一些方法论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.

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

下次讲划分微服务。

devmicroServices

wentao

写点代码,解决点问题。

干了这碗毒鸡汤🥣

hi hugo