浅谈微服务架构选型

微服务架构类型

微服务方面的开源框架很多，很多提供的功能很类似，难免给大家带来选择困难。本文基于最近的选型心得浅谈一下微服务的架构选型。
目前主流的微服务架构分为两大类，基于Framework的微服务架构和service mesh。两者各有优缺点，下面针对这两类架构进行对比。

基于Framework的微服务架构

此类架构采用一个微服务framework来支持微服务架构中的共通关注点，包括服务发现，load balancing, circuit break, tracing. 此类framework可以简化微服务的实现，把共通的处理放在framework层进行处理。代表性的框架有SpringCloud。

基于service mesh的微服务架构

service mesh架构的核心思想是把微服务架构中的共通关注点抽象为infrastructure层，接管服务和服务之间的通讯。在service mesh架构中service 实例不直接处理service和service直接的通讯，而是通过sidecar proxy进行。多个sidecar proxy互相连接可以处理网状的service互联的场景，进一步简化service的实现。代表性的框架有Istio.

两大架构的区别

两大架构都比较全面的支持微服务架构中的关注点，简化服务的开发。两者是通过不同的方式解决微服务架构中的关注点。

SpringCloud通过framework来实现微服务架构中的关注点，服务的开发相对比较方便。不利点：服务的实现代码需要依赖framework。framework的升级会比较麻烦，可能会需要修改服务的实现代码。

Service mesh通过和service独立的sidecar proxy进程来支持微服务架构中的关注点，服务本身只需关注服务的业务逻辑实现，服务本身的代码不依赖sidecar proxy，sidecar proxy的逻辑对serice透明，可以独立升级框架和服务的实现，可以比较好的分离服务开发和服务运营的关注点。不利点：sidecar proxy和service之间通过local host通讯，增加了latency。

架构选型推荐

对于已有服务已经采用SpringCloud之类实现的系统，建议继续采用原框架。
对于新开发的系统，如果评估latency开销对系统影响不大的情况下建议采用Service mesh。