2.6 服务管理者

服务管理者是对服务消费者和服务提供者以及它们之间的通信过程进行全局管理的角色，同时也担任着整个集群的管理工作。

服务管理者关心的几个问题及解决方案如下

1.集群容错问题

服务是以多节点、多实例的形式进行集群化、规模化部署的。集群出现节点、实例故障在所难免，可以允许单点故障的发生，但是不能由单点故障发展成系统崩溃，所以集群中需要有类似熔断器的组件来阻断服务出错的进一步扩大。

2.集群监控问题

服务提供者与服务消费者之间的调用视图、实例之间的调用延迟、各节点的资源使用情况等，需要一个链路追踪系统来跟踪，并呈现追踪结果。

3.集群管理问题

（1）流量控制问题

在一些高并发的系统或场景中，来自各客户端、消费者的请求并发TPS/QPS是非常高的，所以集群需要有网关及流量控制系统来做一定的防护，包括对非法的请求、携带错误参数请求的拦截，对合理流量的分区、限速等，以保护系统不被流量洪峰冲垮。

（2）分布式调用

服务提供者与服务消费者之间的通信，可以采用HTTP协议，也可以采用成熟的RPC协议和自定义协议。调用的方式也需要提供同步调用、异步调用、并行调用等方式。在性能方面，考虑IO模型、序列化效率、线程模型等的优化。

（3）分布式事务

分布式系统因为涉及集群，所以会带来一定的复杂性、零散性，但部分业务上的整体事务要求也是必须满足的，这时就必须引入一些分布式事务的解决方案来满足业务的一致性要求。

4.集群安全问题

集群安全问题包含的范围太广，本小节探讨的是服务化相关的安全问题，数据相关的安全问题见第9章。

（1）访问者的身份安全控制

1）Token认证

服务化是开放访问的，对非法访问必须加以控制防护才能保证系统的安全。常见的有Token认证机制，Token认证过程如图2-10所示。

① 用户携带密码访问API后端。

② 后端传递用户信息到认证服务器（OWIN等），认证服务器返回Token到客户端，服务端可选择存储公钥，这个Token携带了用户的私钥。

③ 客户端存储Token，再次访问时携带Token访问后端。

④ 后端发送Token到认证服务器验证（服务端未存储公钥的情况），通过后返回客户端所需资源。

业界较为常用的解决方案是JSON Web Tokens（JWT），JWT与上述标准认证过程的不同在于服务端存储公钥，客户端再次访问时，不需要再到认证服务器验证。

2）三方认证

三方认证在当前APP之间的互相认证授权中比较常见，如三方登录业务，这种认证方式给用户带来良好的体验。三方认证过程如图2-11所示（以微信用户登录豆瓣网站为例）。

三方授权过程是按照OAuth 2.0规范实现的，OAuth 2.0可以理解为一种允许第三方应用程序合法获取资源所有者对资源处理权的授权凭证，有了这个凭证，第三方程序就可以拥有对资源进行处理的合法身份。

图2-11中4个关键角色的对应关系如下所示。

1）资源拥有者：微信用户。

2）资源服务器：微信服务器。

3）客户端：豆瓣网。

4）授权服务器：微信开放平台。

（2）通信数据的加密控制

双方确认身份后，可以开始建立有效的通信通道。但是在通道中的数据传输仍然有被窃听的风险，在微服务之间的通信过程中，常用的保障措施就是对通道过程进行严格的加密，根据通信方式不同，有HTTPS、对称加密与非对称加密等方式。

在RPC的通信中，常见的加密算法有对称加密AES和非对称加密RSA。

在HTTP协议通信中，常用的是HTTPS，HTTPS即HTTP+SSL（TLS），目前的加密方式一般是客户端与服务器互相协商，找到双方都支持的加密算法，一般都是混合算法，混合了上述的几种算法，这也是HTTPS通信比HTTP通信稍慢的一个原因。

（3）权限控制

有了身份证明，对通信的过程进行了加密后，那么还剩下的安全管控就是对系统资源的分类访问控制了。

一般来说，系统建设时期所考虑的用户都是大量的、多样化的。而由于系统本身业务的复杂性，除了超级管理员这样的角色需要拥有系统的完全权限以外，其他的用户都可以分门别类地对有限的资源进行访问控制，也就是进行权限控制。

常见的权限控制有以下几个控制角度。

1）对业务的控制

不同的用户只能操作对应的业务，不能访问权限以外的业务，这也是最常见的控制类型。例如客服人员不能有财务部门的业务访问权限。

2）对用户的控制

每个用户对资源的需求程度是不一样的，那么对资源进行处理的权限也就不一样。例如普通用户不能观看最新的节目资源，VIP客户才有这个权限。

3）对数据的处理权限

数据对于各类企业来说都是非常宝贵的资产，那么对数据的控制也是要求最严格、精细程度最高的。例如普通用户对报表类数据仅有只读权限、普通管理员对日志仅有追加权限等。