分布式服务框架设计要点

随着业务的发展，应用规模不断扩大，系统内部的巨无霸应用越来越多，常规的垂直应用架构已经无法应对复杂业务带来的各种挑战，通过将业务功能能力抽象成原子服务，对复杂应用进行水平的拆分和服务化，实现服务消费者和提供者的解耦，这就是分布式服务框架要干的活。

---

服务调用

分布式服务框架天生就要对服务生命周期进行管理，服务调用需要支持多种模式：同步调用、异步调用、并行服务调用、泛化调用，另外要注意的是服务与业务之间一般都是通过消息队列进行交互，所以是NIO并不等同于服务的异步调用，他们是2个不同层面的概念。

服务注册中心

服务的提供者和消费者，就像2个互相提防的生意人，不能直接接头，但是又得把生意做好。这个时候怎么办，需要一个服务贩子（中间人）。通过服务贩子（中间人）来传话，或者服务提供者把服务“卖”给了消费者，有时服务提供者也会从其他服务提供者“买”服务。服务贩子界，最出名的要数ZooKeeper了。

服务发布和引用

服务发布，用开发人员比较容易理解的的话就是别人怎么用你开发好的类、方法，最容易理解的方法就是拿个类过来直接new 对象出来，然后通过对象来调用方法，这个是比较简单且粗暴的，还有一些如利用反射机制、代理来调用方法。我们自己开发自己用比较简单，自己开发别人用，就存在环境不同、工程不同等障碍，用起来也不那么容易。

灰度发布

灰度发布时是指在黑与白之间，能平滑过渡的一种发布方式，AB test就是一种灰度发布方式：让一部分用户继续用A，一部分用户开始用B，如果永华对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
为什么要有灰度发布？在互联网公司的朋友们应该深有感触：产品不停的升级、升级再升级，而且服务不能下线，还不能对用户有太大的影响，这个场景用灰度发布就特别适合，总结起来，灰度发布有如下好处：

• 1）解决服务升级不兼容的问题；
• 2）及早获得用户的意见反馈，尽快完善产品功能；
• 3）缩小服务升级所影响的用户范围，降低升级风险；
• 4）让用户及早参与产品测试，加强用户互动。

服务多版本管理

在为服务架构中，微服务独立开发，打包，部署和省级，因此微服务的版本和软件包的版本可以一一映射，但是在实际开发种，特别是大规模企业应用开发，单独为每个服务打包和部署目前尚未成为主流，它会增加服务软件包的管理和线上治理成本，因此目前主流模式仍然是多个服务提供者合设打成一个大的jar/war包，这也会存在一个问题：项目开发初期，各个服务的版本号保持一致；但是运行一段时间之后，有些服务进行了版本升级，有些服务没有，这样他们被打包成同一个软件包时，这就会导致版本号不一致。

流量控制

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。

当资源成为瓶颈时，需要对消费者进行限流，就会启动流量保护策略，举个最简单的例子，淘宝在碰到访问的高峰时期时，就会按照区域和用户价值采取限流措施，如西北地区的用户禁止访问。

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。

更多

请关注微信公众号: