微服务也许是一种文化？

好久没有写有关微服务的东西了。之前写的也都是偏实际操作的类似教程的东西。

今天斗胆想尝试着分享有关微服务什么时候该入场的问题。

就是微服务化这个过程，我们什么时候开始比较合适？以怎样的规模开展比较合适等等。

最近恰好看到一个大牛说了这么一段话：

'If you can’t build a well-structured monolith, what makes you think microservices is the answer?' – Simon Brown

大体意思就是说当你不能够搞出一个架构良好的单体时，那么微服务就是你的答案。

这句话再说直白一点，其实是在说当你无法预料和设计和计划一个完整的大事情的时候，你其实可以分而治之，一点点去搞，这“一点点”其实就是所谓微服务。

微服务与精益思想

由此我也想到了以前看过有关 “精益创业”的事情，相信关注产品的朋友们也会经常在各种培训或书籍中看到这个词。

这里就简单的说明一下：精益创业就是指你先搞个小的，发布给用户去使用，如果觉得势头不对，立马换另外的路。所谓船小好调头。

大道理都是想通的，就是都比较小。小了，自然我们就是我们能直接想到的，距离实际最近的，距离用户最近的。

凡事最怕大，一旦大了就会变得复杂。

由此也可以联系到以前的瀑布式的软件设计方法。为什么瀑布式被后来的软件公司嗤之以鼻，至少是不推崇，也许就是因为 我们无法像上帝那样能够预知未来的一切，我们都是凡人，我们可能只能想到最近的一些事情，往远了，基本上就是在拍脑袋胡编了，就像好多创业公司拉投资，要搞ppt，写什么商业模式，还要写在未来几年的计划，要在某月某日的时候要有多少收益等等。

民间有句俗语叫：计划赶不上变化。相信我们每个人每天都在经历着这样的事情。短期的计划你是可以想到并能践行的。但一长了，有的人就彻底无法规划 了，还有一部分自命胜天半子的人可能会专门列出一些五年规划，下一个十年他敢去往何方之类的。但大部分人都没有这样的计划能力，更何况计划执行的可能性。

说了这么多，其实这些都和我们今天要讨论的微服务这三个字有着本质的关系。那就是“小”、“短”，“近”。

微服务到底该怎么推进？

可能有的朋友说我们只要上面一下命令，我们就全面推进微服务了。这是一种做法，这样的做法也确实够魄力。

但如果从“小”、“短”、“近”的角度看的话，也许我们应该循序渐进的推进微服务

。我们说“微服务化”，既然是“化”，就是一个过程，慢慢传染和蔓延的过程。

之所以这么说，不仅仅是因为 上面的 “精益” 理论和“计划赶不上变化”在支撑着，还因为最近在做一个产品的过程中，我就发现，其实微服务只要你把它当做一种理念后，它会在你开发的过程中自然而然的就想到的一种做法。

比如最近我们在做一个xxxxx，当我们上线了一期的功能后，二期又开始加入新的内容，按照传统的做法，我们就是基于一期的module继续添加内容就是了。

但我们没有这么做，我们把作为新的module添加到项目中。为什么这样做呢？

原因很简单，如果我们继续在现有的module中添加新的deamon守护功能的话，会有所耦合，也就是说在多个deamon守护线程在那里运行，一旦因为某一个流量过大而崩溃，就会导致其他的守护线程也崩溃，产生雪崩。基于这种顾虑我们添加了新的module。下一次上线的时候，这个module也自然是通过单独流水线来发布的，独立的运行在独立的虚拟机或docker之上 。

然而，随着新的需求的不断增加，基于耦合的顾虑，基于风险分散的顾虑，基于风险隔离的顾虑，我们总是会想到一种保守的做法就是 再去新建一个module。然后这个module到时候自然也是独立的上线发布。

于是你就会发现，随着需求的不断开发和新的能力的不断添加，module越来越多，这就面临一个问题，管理问题。你得想办法把这些module给统一的在一个地方管理起来。

于是我们自然想到了使用spring boot admin这种 工具来管理我们的module，也就是一个个运行的spring boot 应用。

然后，你又会想到引入eureka来收集每个运行者的spring boot应用的信息，然后保持和spring boot admin同步。

于是你发现，自己悄悄的开始基于微服务来构建你的产品了。

为了微服务而微服务？

也许在微服务化的过程中，我们并不需要看到大家都在说微服务，我们就开始跟风开始向微服务大规模的迁移。

我们也没必要为了微服务而微服务。

既然外界都在说微服务，我们主动的去了解和研究，然后把这种理念变为自己的工具箱里的一件。

等到那天具体的业务场景下，我们自然而然的就会想到用它来解决当下面临的一些难题或者让现状变得更好。

微服务也许是一种文化

从精益角度也许微服务是一种文化。

甚至是公司文化的一种。

甚至可以说微服务是工程师文化的表现后的一种结果。

因为只有工程师自己才真正的知道应该抽取出哪几个服务，服务粒度多大，具体的边界怎么划分比较好等等。

既然是在一种文化层面的事情，也许就不是简单的使用了哪个微服务框架后你就是真的微服务了。

也许更重要的是，微服务后，真正为你解决了哪些问题。至于使用了哪些方法，哪些框架，也许真的不一定是圈得很死的那几个。

具体问题具体分析。你的公司是否适合微服务，你的应用是否适合微服务。应用本身的特征是一方面，也许还和你所在公司的文化相关。如果你的公司文化更崇尚偏运动式的“大生产”，也许你的微服务化进程或者说真正能解决多少问题且少产生新的问题，恐怕要打一个问号；如果你的公司是更偏向于工程师文化，注重循序渐进和长期演进，那么微服务的这种理念会让你如虎添翼。

以上仅是个人理解，欢迎留言讨论！