微服务这一概念之前只是简单了解没有直接体会,近距离观察一段时间之后有了一些看法。

优点

易于多团队协作

将单一服务切分到微服务之后,容易与实际中的团队组织结构相对应。以服务为粒度,可以交由不同团队进行维护,彼此之间通过RPC等通信协议进行协作。在业务内容与人员都达到一定规模的场景下,这样的切分实际能够划定不同团队之间的工作边界,使得团队之间的协作不那么耦合。

风险隔离,提升稳定性

单一系统遇到问题的时候很容易造成整体服务不可用,拆分微服务之后,很多问题只会在局部服务中出现,问题的影响范围可以得到控制,提升了系统整体的稳定性与可靠性。

便于定向优化

服务拆分之后,局部的性能问题可以有更多的手段与策略进行优化。优化的成本与风险都会相较单一服务低。堆机器这种粗暴方案也能更有针对性。

降低技术升级的心智负担

如上所说单独的服务即使遇到问题,影响的范围也相对可控,因此更利于进行一些技术升级改造。当然,实际上的优化升级往往都是很漫长的过程,但那更多是愿不愿意改的问题,而不是敢不敢改的问题。

降低成本

当系统的复杂性达到一定量级之后,微服务化不仅仅从资源层面可以让硬件资源针对部分服务进行适配,提升资源利用率。另一方面也可以降低系统维护复杂度,微服务自身的复杂度与系统整体的复杂度相比减轻了很多,对于维护的人员来说,可以筛减掉很多无需关心的内容。

缺点

问题排查变得复杂

原先可以在一处解决的问题,变成了一系列RPC调用。原本可能就是代码逻辑问题,现在则可能是RPC下游的服务可用性问题,RPC调用的网络问题。在问题排查定位上,需要关注的因素会更多。

服务运行环境变得复杂

单一服务很容易进行部署,微服务之后服务之间的依赖关系使得微服务的部署变得复杂。不同环境、不同版本所需部署的微服务都有各自的需求。

沟通协调增加

微服务之间的依赖关系,使得在某些服务升级变更的时候需要沟通上下游,增加了沟通协调成本。

响应时间增加

不同服务之间的RPC调用肯定比本地的函数调用慢,网络调用开销的增加是不可避免的。如果服务链路过长,那么受到的影响就更明显了。

关键点

服务切分合理性

微服务的关键问题是如何进行划分,如何控制服务的粒度。服务切分得不好会带来后续一系列问题。如何切分这件事情和业务场景相关,也和实际人员的经验能力相关。

服务依赖可视化

微服务之间的依赖关系需要以简明直接的方式进行展现,这样有利于在服务切分不合理的时候第一时间发现。

调用链路追踪

微服务之间的调用链路一定需要进行追踪,否则问题排查是无从进行的。

监控预警

当微服务数量达到一定量级,局部出现问题总是无可避免的,这种情况下完善的监控预警就显得尤为重要了。否则在遇到问题时容易抓瞎。

代码框架与公共服务统一

微服务化之后也会继续出现新的业务逻辑与场景,这就意味着会继续微服务化。那么代码层面的一致性与底层框架公共服务的可用性、易用性就变得很重要了。

程序语言的统一

理论上微服务之后服务之间只要保证协议即可,使用什么语言都可以。但实际上需要进行控制,多语言的成本太高,完全没有必要。