一个服务中心不单单是在企业的几个应用中发挥作用,它可能会给企业上百个不同的应用提供专业服务,一旦这个服务中心出了问题,将会对业务的运营产生估量的损失和影响.
服务稳定性,服务能力的扩展性,服务需求的快速响应能力提出了前所未有的更高要求.
技术框架选择
平台能力
技术实现
分布式服务框架的选择
过去:
几百个人维护一个几百兆的WAR包模式:
1 项目团队间协同成本高
2 应用复杂度已超出人的认知负载,一个小小的功能改动可能会给其他功能带来未知的风险,整个平台给人一种牵一发而动全身的感觉
3 错误难以隔离
4 数据库连接能力很难扩展
5 一个包含几百个功能的WAR包所需要的初始和运行资源就不会太小,我们发现系统在出现业务处理瓶颈的时候,只是由于某一个或几个功能模块(比如在大促)负载较高造成的,但因为所有功能都打包在一起,所以此类性能问题并且需要通过
增加应用实例的方式分担服务负载时,则没法对单独的几个功能模块进行服务能力的扩展,而只能将整个完整的应用进行扩容.带来了资源额外配置的消耗,成本较高
现在是基于SOA理念进行了分拆
SOA的主要特性:
1 面向服务的分布式计算
2 服务间松散耦合
3 支持服务的组装
4 服务注册和自动发现
5 以服务契约方式定义服务交互方式
传统企业是的ESB是以中心化理念实现了SOA,而几乎所有的互联网公司均基于去中心化分布式服务框架建设系统,其根本原因就在于扩展性是首要的
去中心化分布式服务框架对于SOA特性的实现,相比中心化的服务框架,最重要的不同就是服务提供者和服务调用者之间在进行服务交互时无需通过任何服务路由中介,避免因为中心点带来平台能力难扩展问题.
而对于不同技术接口的支持,数据格式转换,服务动态路由等功能就没有在去中心化的平台中有所体现,更多情况是依靠服务应用的编写来满足这样的需求.
当整个平台或企业内的应用都是基于服务化架构建设的时候,一次网页上的点击请求就不会像之前那样,所有的代码逻辑都在一个应用实例中就能完全处理,而需要通过调用多个远程的服务来完成整个业务请求的处理.
拿大家熟知的淘宝订单创建举例.在淘宝上点击"立即下单"或"结算"按钮进行下订单的请求时,后端调用了200多个服务,也就是一次页面请求产生了后端上百台不同服务器间的服务交互.
阿里的分布式服务框架HSF
HSF的开源版就是Dubbo,
HSF服务框架的组件：
1 服务提供者，一般是集群部署，每一个HSF的应用均是以WAR包的形式存在，运行在阿里定制的tomcat容器里，在tomcat容器层已经集成了HSF服务框架对服务提供者或服务调用者进行配置服务器发现，服务注册，订阅，失效转移等相关功能，
所以不管是服务提供者还是服务调用者开发时，只要进行服务相关的配置操作，应用中无需引入任何HSF相关的Jar的依赖包。近几年以Docker为首的容器技术的发展，现在阿里内部也正在进行应用容器化部署工作。
2 服务调用者 大多数也以WAR应用包的方式运行在tomcat容器中
3 地址服务器 在HSF服务框架中肩负这给服务提供者和服务调用者提供部署环境中所有配置服务器和Diamond服务器的服务器列表信息，是由nginx提供该服务能力。在部署HSF服务环境时，会将整个环境中的配置服务器集群（服务器IP列表）和Diamond服务器集群信息设置在地址服务器上，在实际生产部署中，也会部署在多台地址服务器提供负载均衡和高可用性的服务，服务提供者和调用者通过统一域名（比如xxx.tbsite.net）的方式访问这些地址服务器，通过DNS轮询实现地址服务器访问的高可用性。
4 配置服务器 配置服务器主要负责记录环境内所有服务发布者的IP地址端口和服务调用者的ip端口信息，并将服务相关信息推送到服务节点上，为了追求服务发布和服务订阅的推送效率，所有服务发布和订阅信息均是保存在内存中
配置服务器和所有的服务提供者和调用者均是长连接，采用心跳的方式监控个服务运行节点的状况。一旦出现服务提供者服务节点出现故障时，会自动推送更新后的服务提供者列表给相关的服务调用者端
在生产环境会部署多台配置服务器用于服务发布订阅推送的负载均衡，在多台配置服务器间会进行实时的数据同步，保证服务发布和订阅信息尽快同步到各服务节点上。
在某种程度上，配置服务器在HSF框架中扮演了服务调用调度的指挥官，通过给服务调用者端推送不同的服务提供者列表就可以轻易的调整服务调用的路由，这一特性在淘宝平台实现单元化，异地多活祈祷了至关重要的作用。
5 Diamond服务器，本质上是一个通用的统一配置管理服务（类似zookeeper），给应用提供统一的配置设置和推送，在HSF服务框架中，Diamond服务器主要承担了服务调用过程中对于服务调用安全管控的规则，服务路由权重，服务QPS
阀值等配置规则的保存，所有的信息均是持久化保存到了后端的MySQL服务器中，在生产环境中，会有多台Diamond服务器提供负载均衡的服务。使用Diamond服务器进行服务相关设置的典型场景：
- 通过设置白名单的方式，设置某些服务或服务中的方法只能让特定IP地址的服务器调用
- 通过用户认证的方式控制服务是否能够调用
- 按照不用的服务器权重设置服务调用者对多个服务提供者服务节点的访问
- 设置某些服务的QPS能力限制，一旦该服务的QPS达到了该阀值，则拒绝服务的继续调用，这也是实现服务限流的技术实现，在平台进行大促或秒杀场景时，保障平台稳定性的重要屏障。
通过这样的规则设置，Diamond服务器除了将这些规则保存在自身的数据库中，会自动将这些规则推送到相关的服务节点上（同步），使这些规则能立即在服务运行环境中生效
接下来具体介绍HSF框架如何给服务提供以上能力:
HSF框架采用Netty + Hession数据序列化协议实现服务交互
在服务提供者和调用者间有多个服务请求同时调用时会共用同一个长连接，即一个连接交替传输不同请求的字节块。既避免了反复建立连接开销，也
避免了连接的等待闲置从而减少了系统连接总数，同时还避免了TCP顺序传输中的线头阻塞问题。
Hession是HSF框架中默认使用的数据序列化协议，在数据量较小时性能表现出众，Hession的优点是精简，高效，同时可以跨语言使用，同时Hession可以充分利用Web容器的成熟功能，在处理大量用户访问时很有优势，在资源分配，线程排队，异常处理等方面都可以由web容器保证，HSF框架同时也支持切换使用JAVA序列化。虽然hession不是最快的序列化协议，但它对于复杂业务对象的序列化正确率，准确率相较于最稳定的java序列化并不逊色太多，其他的序列化协议相较于hession复杂场景的处理能力较弱
2 HSF的容错性
3 HSF框架的线性扩展支持
HSF框架最为重要的一个特性就是服务能力的可扩展性。
只需要通过增加该服务的服务提供者实例，可在几秒内（主要完成服务注册发布，更新后服务列表推送到服务调用者端）开始进行服务请求的处理，从而达到分担其他服务器实例压力的作用，实现服务能力整体水位恢复到正常的状态。
