聊聊微服务的优缺点

最近进行了一次公司的服务拆分，将两个巨大的服务拆分成了若干个微服务，现在总结下这次改造的经历。

 1、项目背景

刚来到公司的时候领导叫我熟悉下公司的业务，看看代码。我也是做着常规操作，下载代码，编译，打开APP,WEB,WAP等平台对照着几个重点的功能从webapi层逐级向下展开。BUT，重点来了，我发现几乎百分之八十的功能实现都调到了两个服务，并且业务复杂代码杂乱无章，看着看着就看不下去了，后面分配任务给我也是小心翼翼，生怕对其他地方有什么影响，发布的时候还要同步验证其他功能。在这种背景下服务拆分就被提上了日程。

 

上图是一个简单的依赖关系，所有的核心业务都被封装到了ServiceA 和 ServiceB当中

 

2、什么叫微服务

微服务其实是一种架构体系，顾名思义是细小的服务单元。各个服务之间通过RPC调用组合编排实现整个完整的业务逻辑。

 

3、微服务的优点

 

1）我觉得最大的优点就是业务清晰，每个服务只需负责单一的业务逻辑，对于上层调用来说是透明的并不关心你的具体实现，这样业务梳理起来会比较方便。

2）第二点我觉得就是细小的服务单元进行需求迭代起来会比较方便，不必过分担心我的修改对其他代码造成的影响，并且对于新人熟悉代码也会更加的快速，对代码各部分了解比较清楚出现问题的时候能快速的定位。

3）第三点就是对于服务的水平扩展。有可能只是某个业务的调用量比较高，需要更多的机器支撑，那么就可以单独的对哪一个服务进行横向扩展。

4）最后就是技术的选型不受限制。因为各个服务之间的调用都是通过RPC进行的，所以理论上只要支持跨语言的RPC框架都可以使用。但是现实一般公司为了维护和管理方便会同意使用同种技术。

 

4、微服务的缺点

 

1）我觉得最大的缺点就是不能低估微服务带来的复杂性。各个服务之间的调用如何保证事务？如何保证数据的一致性？如何保证RPC调用的稳定性？等等一系列的问题会等待解决。

2）第二点就是服务的部署。比如ServiceA依赖ServiceB,ServiceB又依赖ServiceC，那么如果服务A想上线不许等待服务B和C正常上线后才能进行，这无疑会增加团队协作的复杂性.

 

5、总结

总的来说微服务的架构给系统带来了一定的好处也带来了一定的坏处。微服务的目标是通过拆分实现项目的敏捷开发和部署。所以在进行架构选型时还是有必要进行一定的利弊权衡，没有最好的架构，只有最合适的架构！