如何从单体架构平滑过渡到微服务

　　一旦决定在开发实践中引入微服务架构，如何将积累下来的庞大的巨无霸系统润物细无声的过渡到微服务架构将是一个巨大的挑战。同程旅游微服务开发团队给出了他们的建议。

　　他们认为推倒重来不可取，架构师们最想通过微服务化取代的部分，往往是公司的主要盈利核心，改造难度不亚于飞行中更换引擎。从业界公开的信息来看还没有哪家做到了完美升级， 更多的可能无外乎两种：

• 第一种改造后苟延残喘，研发疲于奔命；
• 另一种则是改造中就直接休克。

　　因此为使微服务能顺利的应用，架构师从不应该幻想一蹴而就，可以从以下三个方面采取行动。

1. 培训先行

　　技术人都善于把面临的问题变成技术问题，然后在自己最擅长的领域去把它解决。这就造成一个悖论：能用技术解决的问题就不是问题，真正的问题在受限的情景下仅靠技术是解决不了的，实施微服务最大的拦路虎也不是技术本身。

　　从同程微服务团队的实践来看，最大的问题不是如何做好微服务，而是就微服务应该是怎么达成一致的看法。

　　因此，可以在实施前通过多数人参与大讨论或培训，使认知达成一致。这类似编码规范中的命名规范，使用那种命名方法不重要，重要的是人人都使用同一种命名方法。

2. 绞杀者模式

　　绞杀者模式是指，对于无法通过修缮者模式改进的系统，在系统外重新构建新功能来逐步剥离重构，对功能服务逐个绞杀。好处是不影响原来的环境，一旦条件成熟就能快速切换。而缺点是可能需要一段时间同时维护两套系统，付出额外的开发维护成本。

3. 监狱模式

　　这是同程内部的叫法，允许一些短期无力改动的系统通过监狱窗口（MicroProxy）接入微服务平台并委托 Proxy 将其暴露成微服务，单体架构往往拥有庞大的服务接口梳理， 往往需要开多个监狱窗口。

每个监狱窗口都会被包装分割成微服务，条件成熟了能很方便的替换成原生微服务，称为刑满释放。

　　以上就是今天的内容，希望能对你有所帮助。

来源：极客时间