这是我参与8月更文挑战的第3天，活动详情查看：8月更文挑战
一旦决定在开发实践中引入微服务架构，如何将积累下来的庞大的巨无霸系统润物细无声的过渡到微服务架构将是一个巨大的挑战。
架构师们最想通过微服务化取代的部分，往往是公司的主要盈利核心，改造难度不亚于飞行中更换引擎。从业界公开的信息来看还没有哪家做到了完美升级， 更多的可能无外乎两种：
- 第一种改造后苟延残喘，研发疲于奔命；
- 另一种则是改造中就直接休克。
因此为使微服务能顺利的应用，架构师从不应该幻想一蹴而就，可以从以下三个方面采取行动。
1. 培训先行
技术人都善于把面临的问题变成技术问题，然后在自己最擅长的领域去把它解决。这就造成一个悖论：能用技术解决的问题就不是问题，真正的问题在受限的情景下仅靠技术是解决不了的，实施微服务最大的拦路虎也不是技术本身。
从同程微服务团队的实践来看，最大的问题不是如何做好微服务，而是就微服务应该是怎么达成一致的看法。
因此，可以在实施前通过多数人参与大讨论或培训，使认知达成一致。这类似编码规范中的命名规范，使用那种命名方法不重要，重要的是人人都使用同一种命名方法。
2. 绞杀者模式
绞杀者模式是指，对于无法通过修缮者模式改进的系统，在系统外重新构建新功能来逐步剥离重构，对功能服务逐个绞杀。好处是不影响原来的环境，一旦条件成熟就能快速切换。而缺点是可能需要一段时间同时维护两套系统，付出额外的开发维护成本。
此模式有助于将迁移的风险降至最低，并可在一段时间内分散开发工作。 由于外层将用户安全路由到正确的应用程序，你可按自己的节奏将功能添加到新系统，同时确保旧版应用程序继续运行。 随着时间推移，功能迁移到了新系统，旧版系统最终受到抑制，并且没有存在的必要。 此过程完成后，可以安全停用旧版系统。
3. 代理模式
允许一些短期无力改动的系统通过代理（MicroProxy）接入微服务平台并委托 Proxy 将其暴露成微服务，单体架构往往拥有庞大的服务接口梳理， 往往需要开多个代理窗口。
每个代理窗口都会被包装分割成微服务，条件成熟了能很方便的替换成原生微服务，称为解除代理。
