学习微服务——分布式服务及治理

1.2.3 分布式服务及治理

1.2.3.1 亘联网服务化

在互联网领域，大型网站基本都是从一个小站点逐步演变而来的。这点和企业级应用很不一样，企业内部的系统建设一般都是先由特定的一批人的需求零星独立建设的，系统多了，有了互联互通的需求之后，才开始做整合。当网站的业务规模很小的时候，采用的也是类似如图1.1所示的单体架构，随着业务的快速发展，站点的所有功能都堆积在一个系统中的问题就开始显现，包括功能模块及代码互相耦合、资源冲突、维护麻烦、编译时间变长等，这些单体应用会遇到的问题，网站也都会遇到。除此之外，膨胀的单体架构对网站还有另外几个致命的影响。

• 对SAP-ERP、Oracle-DB这类典型的企业级软件而言，产品版本以年为单位发布;而对一个快速发展的站点而言，为了适应业务的发展，往往需要不断试错，会频繁上线新功能，并根据用户的使用体验进行迭代更新。这会导致频繁发版，频率甚至会达到每天几十次。如果采用单体架构，仅编译就需要十几到几十分钟,测试和发布部署都极其麻烦，完全无法适应业务的快速发展。
• 一个站点各个功能的访问总是不均衡的，比如对购物网站来说，商品列表页和详情页的访问频度总会很高，一个秒杀的功能甚至会导致瞬时几十倍的流量暴增，而评论、客服这类功能的使用频率相对较低。如果这些功能都堆积在一个单体架构中，高频应用将占据绝大部分系统资源，就会导致其他功能的资源受挤占，从而影响用户体验。

基于如上种种问题，一个网站发展到一定规模之后，往往会将业务按产品线进行拆分。比如，美团就将旗下业务拆分为美食、酒店、电影、购物这几大产品线，归不同的业务团队负责。

业务映射到技术上，技术架构及部署策略同样需要跟随产品线进行同步拆分，将一个网站拆分成许多不同的应用，并独立部署和维护。研发团队也相应地拆分成不同的产品线团队，各自负责不同业务系统的研发及维护。

网站系统和企业系统的一点不同在于，它在数据资源的唯一性上做得比较彻底。比如，在企业系统中，集团公司的办公系统可以只有集团公司的用户，分公司的办公系统可以只有分公司的用户，这两套系统之间的公文传输可以通过ESB来完成。在系统建立初期，实际上并不强制一定要有一套统一的用户中心(例如 LDAP)。而对于网站来说，初始的用户体系就必须只有一套，一个用户ID能在各条产品线中通用，一个用户在网站的所有系统中只有唯一的一套标识(俗称 oneID)，否则，用户根本无法在网站中进行随意跳转。所以，大型网站的用户信息这类基础数据往往都存储在同一个数据库（集群）中。如果每个应用都直接连接用户数据所在的数据库，就算每个应用节点只分配几个连接，在集群规模下，总的连接数也将达到几万甚至几十万个，这完全超出了数据库的连接数上限，会导致数据库连接资源不足，从而拒绝服务。

这时候就要考虑服务化的架构了，既然每一个应用系统都需要执行许多相同的业务操作，比如用户管理、商品管理、仓储管理等，那么完全可以将这些通用的业务提取出来，独立部署。由这些可以复用的业务连接数据存储层，提供共用的业务服务，这样应用系统就可以做得比较薄，而把逻辑集中到后台服务中，由共用业务服务完成具体业务操作。具体架构如图1.14所示。

服务化的架构分层带来了很多的好处。

服务化在很大程度上解决了复杂性扩散的问题。比如，随着并发量越来越高，用户管理的

访问数据库成了瓶颈，需要加入缓存来降低数据库的读压力，于是架构中引入了缓存，如果没有统一的用户管理服务层，各个业务线都需要关注缓存的引入导致的复杂性，而由于统一的用户管理服务层的存在，可以将缓存操作集中在这里进行，各个前端应用则对此无感;另外，随着数据量越来越大，数据库需要进行水平拆分，于是架构中又引入了分库分表，如果有了统一的服务层，分库分表策略集中在服务层进行即可，各个业务线都不需要关注分库分表的引入导致的复杂性。

天下武功唯快不破，“快”就意味着机会，尤其是在这个竞争充分、变化快速的社会中，服务化带给业务最大的好处就是，可以让业务系统迅速适应业务高速发展的需求。通用业务及基础技术能力下沉，这些能力从业务系统中剥离出来之后，由专门的部门或者组织维护，业务应用就可以变得更轻、更专注，开发者更多的时候就可以通过很少的代码把这些服务聚合起来，封装成业务功能暴露给用户。业务系统更小、更轻，意味着可以更频繁地上线，更快速地修改，更快、更简单地聚合出新的功能推给市场，只有这样才能支持业务不断试错。服务化做得好的架构，必然是服务层越来越厚，业务层相对较薄，如图1.15所示的就是一个典型电商平台的分布式服务化架构。

1.2.3.2分布式服务框架

随着服务化的不断深入，被下沉的服务数量越来越多，另一方面，随着流量的增大，单个服务的集群规模不断扩大,这就迫切需要一个统一的分布式服务框架来对服务进行集中的管理。参考企业级SOA架构，互联网领域提出了“轻量化SOA架构”，仍然引入服务注册机制和远程调用机制，负责服务的注册、发现、路由、调用等典型的SOA能力，但是摒弃了复杂的服务编排和低效的协议适配（同构系统中，兼容多种协议的需求意愿并不强)。

互联网领域的分布式服务化虽然复用了SOA 架构（做了简化)，但依然有很大的不同。首先，由于互联网服务具有普遍集群化的特点，需要在分布式服务框架中引入服务负载均衡的机制;针对互联网服务流量大、并发高、可靠性要求高的特点，在分布式服务框架中还引入了限流、降级、熔断等保护机制。这些对服务的管控和运维能力被下沉到框架层面之后，可以让业务开发人员专注于业务逻辑实现，避免冗余和重复劳动，规范研发、提升效率。

分布式服务化比起企业SOA 的另外一大不同就是规模。规模上去了，一些原来靠人工完成的功能就不再适用了，比如SOA中的UDDI服务注册，采用的是手工注册的方式，而在分布式服务框架中，服务注册中心则采用了服务运行时自动注册和自动发现的机制。而且，随着云计算技术的快速发展，大型互联网企业往往建设自己的云服务平台，中、小型网站也可以购买第三方的云服务。结合云服务的资源编排及调度能力(IaaS，资源即服务)，应用服务的上线、调配可以采用自动化、批量化操作。因此，分布式服务的自动化程度要比企业 SOA高。如图1.16所示为互联网分布式服务框架的典型架构。

1.2.3.3 分布式服务治理

同SOA类似，分布式服务同样面临治理的需求，同时由于服务集群规模大，梳理服务之间的结构及依赖要比之前更困难，很难靠人工完成，因此分布式服务治理的自动化程度要远高于SOA治理。这个时期的服务治理不仅包含服务的度量，还会根据一些预定义策略，自动执行服务管控的操作。比如，一旦监控到某个服务的调用失败率超过SLA中预先定义好的阈值，服务自动触发熔断保护机制。“自动化”是服务治理在这个时期的一大特点。

分布式服务治理包含服务度量和服务管控两大部分。服务度量具体如下:服务基础信息:包括服务唯一标识、访问协议、版本和归组等信息。

• 服务管理信息:从ITIL这类运维管理系统中获得的对服务管控的相关运维管理信息。服务质量（健康度):根据被调用服务的出错率、响应时间等数据对服务健康度进行的评估。
• 服务依赖:根据服务直接的调用及被调用关系,推导出服务与其上下游服务的依赖关系。同时根据监控获取的调用数据，评定依赖的强弱关系。
• 服务分布:提供服务在物理空间上的拓扑分布情况，包括服务在不同计算中心、不同机房，甚至不同机架上的分布情况。
• 服务容量:根据所提供服务的总能力及当前所使用容量进行的评估，其中能力是指对于请求数量方面的支撑情况。
• 服务调用:服务在线上被调用的次数及基于此的一些统计分析，包括TopN的一些统计排行等。

通过服务度量，就能够对线上服务的运行状况有一个清晰的了解，并据此做出相应的服务管控动作。当然，也可以结合基于行业领域知识和运维场景领域知识的运维专家系统，做自动化的管控。接下来，再从服务管控的角度看看都能对服务做哪些操作。

• 服务上、下线:服务的批量上线部署及批量下线。服务路由:对服务路由策略的管理。
• 服务限流:针对高流量导致的服务负载过高的一种保护机制。服务降级:在异常情况下，保证服务基本可用的一种保护机制。
• 服务熔断:是服务降级的一种特殊体现，主要防止在异常状态下，服务出现“雪崩”状况。
• 服务授权:针对服务调用者对某些敏感服务的访问授权管理。

以上治理的相关详细内容，将在后续章节中详细讲解。图1.17描述了互联网分布式服务及其治理之间的整体关系。