「系统架构」微服务探究之初识微服务

前言

在传统的开发中，咱们一般是将全部的功能打包在一块儿，而后统一部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等全部逻辑。以下图所示：

 

这种开发方式虽然操做简单，代码重用率高，没有分布式的管理和调用消耗，可是因为代码功功能耦合在一块儿，一般是牵一发动全身，一个微小的问题，均可能致使整个应用挂掉。这对于大型应用来讲，是很不可行的。所以，有人提出能不能将每个小的服务独立开来，分别部署维护呢？如产品服务独立成一块，订单服务独立成一块，用户服务也独立成一块。这样，每个服务之间都不会有高耦合性，后期维护升级也更加方便。

 

是的，将每个服务独立部署分开维护，的确能够解决传统开发中的高耦合性，可是咱们也要考虑在传统的开发方式中全部的服务都是本地的，UI能够直接调用，如今按功能拆分红独立的服务，跑在独立的服务器或进程中，客户端UI如何互相访问呢？

后台有N个服务，前台就须要记住管理N个服务，一个服务下线/更新/升级，前台就要从新部署，这明显不服务咱们 拆分的理念，特别当前台是移动应用的时候，一般业务变化的节奏更快。

另外，N个小服务的调用也是一个不小的网络开销。还有通常微服务在系统内部，一般是无状态的，用户登陆信息和权限管理最好有一个统一的地方维护管理（OAuth）。

所以，基于这些考虑，在上面的基础上，有人又提出加入API网关层，用它来处理如下问题：

• ① 提供统一服务入口，让微服务对前台透明
• ② 聚合后台的服务，节省流量，提高性能
• ③ 提供安全，过滤，流控等API管理功能

 

至此，一个简单的微服务架构就诞生了。

服务之间如何通讯

将每个服务独立部署后，确定不能像传统开发中使用类库嵌套的方式调用其余服务。在微服务架构中，服务与服务之间的通讯一般有两种方式：

• ①同步调用
• ②异步调用

其中，同步调用又包括RPC方式和REST方式。

通常同步调用比较简单，一致性强，可是容易出现调用问题，性能体验上也会差些，特别是调用层次多的时候。

而异步调用在分布式系统中有特别普遍的应用，如异步消息，它既能下降调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干本身该干的活，不至于被后台性能拖慢。不过须要付出的代价是一致性的减弱，须要接受数据最终一致性。还有就是后台服务通常要实现幂等性，由于出于性能的考虑，消息的发送通常会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）。最后就是必须引入一个独立的broker，如 果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。

 

服务注册

在微服务架构中，通常每个服务都是有多个拷贝的，每个拷贝之间采用负载均衡的方式参与业务处理。一个服务随时可能下线，也可能为应对临时访问压力增长新的服务节点。那服务之间如何相互感知？多个服务如何管理呢？

这就设计到服务注册了。服务注册一般有客户端方式和服务端方式两种。不过其基本原理都是经过zookeeper等相似技术作服务注册信息的分布式管理。当服务上线时，服务提供者将本身的服务信息注册到ZK（或相似框架），并经过心跳维持长连接，实时更新连接信息。服务调用者经过ZK寻址，根据可定制算法， 找到一个服务，还能够将服务信息缓存在本地以提升性能。当服务下线时，ZK会发通知给服务客户端。

 

服务异常处理

前面提到，为避免传统开发方式把全部鸡蛋放在同一个篮子里，一荣俱荣，一损俱损的问题，人们转而采用服务独立部署的方式，但独立部署有一个很大的风险就是网络是不可靠的，即网络可能出现故障，若是这一块没有特别的保障，采用微服务架构结局确定也是噩梦。那微服务如何保证总体业务链路不受网络的影响或者把受到的影响降到最低呢？关于这一方面，微服务主要采用如下几个手段：

1. 重试机制：多试几回
2. 限流：减小到该服务的请求
3. 熔断机制：关闭该服务与其余服务之间的联系
4. 负载均衡：将指定请求分配到指定服务
5. 降级（本地缓存）：暂时关闭某些无关服务