微服务改造的六大原则

很多企业一开始并没有使用微服务架构，而是需要从传统架构演变到微服务架构，在进行微服务改造的过程中要遵循六大原则。

1.不要为了使用微服务而使用

有些公司不考虑实际的业务场景和用户规模，一律采用微服务架构开发，目的只有一个，就是让自己的系统看起来高端而已。对于一些中小企业的内部管理系统，用户数量较少，业务也不复杂，变化极少，这时采用单体架构可能是一种更加简单高效的做法。

2.不要妄想完美架构_，要用进化的眼光看架构

要清楚地认识到不存在完美的设计和架构，很多人在系统设计初期就希望考虑到所有问题，把系统设计得极其庞大、复杂，尽量地去除所有的耦合，导致前期开发投入巨大。但是，随着业务的发展，发现业务量根本没那么大，或者架构依然要进行很多的改造。淘宝网早期也是单体架构，一个WAR包支持所有服务，经过十来年的不断演进才形成了分布式微服务架构，好的架构是不断迭代、升级、改造出来的，而不是一蹴而就建造出来的。

3.微服务拆分没有绝对的标准

把每个接口作为一个微服务，或者把10个接口作为一个微服务，或者按照代码量拆分，多少行代码拆分为一个微服务。在笔者看来这种做法是不妥的，应该按照业务高内聚、低耦合的原则，先按照领域进行划分，再按照业务量进行划分。例如，一个电商系统可以拆分为用户、产品、库存、支付几个微服务，如果业务量较大，则可以继续拆分，如支付服务可以继续拆分为集团支付、个人支付、对公支付、对私支付、单笔支付、批量支付等微服务。

4.不要忽略非功能性设计

例如，交易统计、埋点分析、日志收集、链路追踪等，由于这些设计并不会影响业务的正常流转，所以经常被忽略。随着业务复杂性不断升高，微服务数量不断上升，交易链路变得越来越复杂。当要排查一些问题时，我们就会变得十分被动和痛苦。例如，淘宝的一次下单交易，涉及两百多个微服务的相互协作，如果没有完整的链路跟踪、日志记录、交易分析的工具，则是不可想象的。一次交易涉及五六个服务协作，开发人员就很难记忆了，更何况这种交易很多，完全靠人脑和文档记忆是不现实的。

5.环境网络隔离_、权限隔离

使用微服务的好处是只要服务注册到注册中心上，就可以被其他服务感知到，就可以提供服务。如果因为误操作导致把测试环境的微服务注册到了生产的注册中心上，就会导致生产数据落地测试环境，后果十分严重，相反生产环境注册到测试环境，也需要隔离。

6.重视容器化持续集成和部署

一旦大面积应用微服务架构就会面临服务节点快速增加，依赖关系复杂的问题。进行系统发布时就不单单只是一个WAR包的问题了，而是需要考虑先发布哪个节点，后发布哪个节点，如何进行自动化编译、打包、测试、发布，因此容器化持续集成和部署就变得至关重要。