上一篇文章我们讲述了微服务转型前的考虑与注意事项，接下来我们可以探讨过渡到微服务的策略与其他一些需要注意的问题。

迁移架构前，你需要想明白：从整体代码库创建或分解哪些服务；你的架构设想是什么样的；你希望服务的粒度是多大；以及服务间如何通信。我们可以从那些比较不易分离的服务开始着手，例如那些部署频率或更新频率较高的服务。

迁移到微服务本质上是一种重构，因此我们平时重构所遵循的法则在这里也适用。

过渡到微服务的策略

过渡到微服务有几种策略可供选择，每种策略都各有优点和缺点，在选择策略前应配合实际情况加以考虑。

1. 逐步迁移策略

从原应用中逐步将服务独立出来，慢慢将整体架构转移为微服务架构。 这个过程是循序渐进的，所以在开始时原代码库和微服务会同时存在。

• 优点：逐步迁移到微服务，风险较低，不会影响正常运行时间和用户使用。
• 缺点：由于是一个稳步渐进的过程，需要的时间会比较长。

2. 混合架构策略

混合架构是说同时支持原有的单体架构和新增的微服务架构，原有的应用整体不变，只对新功能采用微服务的形式。这种策略主要是针对那些认为应用太大不能重构，相比重构更愿意保持原样的企业。很明显，混合架构不会解决原架构已经存在的问题，但它能够解决产品未来拓展的问题。 这种混合架构要求新增的微服务能无缝地叠加在原来的应用上。

优点：快速，无需在原应用上做太多工作。
缺点：无法解决原应用已存在的问题，并且可能需要创建新的API以支持面向微服务的功能。

3. 全盘否定策略

这种策略是直接否定旧的架构，直接全部重构。为了保障业务最大限度持续且正常运行，这种策略很少被采用。重构过程中也许仍会通过补丁来支持旧应用，但是新功能都会使用微服务来实现。尽管这种做法冒的风险可能比较大，但仍然会有企业愿意采取这种策略，因为他们觉得旧的架构实在是难以让工作继续开展。

优点：允许企业重新思考工作方式，从头开始有效地重写应用。
缺点：它需要从头开始重写应用；最坏的情况是用户业务受阻，必须要等到新架构完成才能正常使用服务。

版本控制

除了策略的选择，服务间的版本控制也需要加以考虑。

由于微服务里每种微服务都可以通过特定的API互相访问，无需了解各自的底层实现逻辑。因此，当某个服务需要进行更新、修复错误或改进性能时，只要它的API接口没有变化（地址、请求参数等没有改变），那么使用到这个微服务的其他微服务仍然可以像之前一样正常工作。

而当某个服务进行更改时，一下将所有流量路由到更新后的服务是比较冒险的。如果更新后有问题，那么所有用户都会受到影响。有一种发布方法叫灰度发布，在新服务发布时，先转移一部分用户流量到新服务，监控这部分用户的使用情况，等到确认服务没有问题，再将所有流量转移到新服务。灰度发布可以通过部分流量验证新服务的发布情况，从而避免大概率甚至是致命的错误发生。

通过API网关将流量从原应用路由到微服务应用

通过网关使用灰度发布转移流量

库与安全

在重构过程中，可能会涉及到第三方库的问题。一般而言，若是单个微服务引用了某个第三方库，处理的逻辑也仅由一个微服务实现，若这个第三方库有任何改动，影响的只会是一个微服务。若多个微服务同时引用某个第三方库，那么库的更新会同时影响多个服务，此时会引发连续的重新部署。

微服务与第三方库

一般来说，如何引用第三方库很难给出一个通用的答案。但从长远来看，任何妨碍微服务单独部署的事情都应该避免。

引入微服务之后，我们还需要处理身份验证和授权的问题。授权也可以通过像API网关这样单独的一层来实现。考虑到越来越多的微服务加入进来，或许还需要重新设计身份验证和授权，必须确保未授权客户端将无法使用它们。 同时应该启用日志全面记录和监控微服务的运行。系统的全面监测变得尤为重要，最好能够为每个服务配置健康检查，一旦某服务的出错概率达到阈值，则停止使用该服务，防止影响系统运行。

小结

过渡到微服务是一项重大的工程投资，但是它的作用是显而易见的，每个行业的企业都在接近或部署微服务架构，同时，这样的重构不只是代码上的，也是开发团队上的。