关于中心化和去中心化的问题，已经是老生常谈了。中心化的优缺点都很明确，优点就是容易部署、容易维护，在服务压力较稳定的情况下，是成本最低的解决方案。缺点也是很显然，功能复杂之后管理困难，冲突频繁，性能不易线性扩展，容易单点故障。去中心化或者说分布式就是为了解决这个问题而出现的。

搭建企业级的中台，意味着所有前台的请求都会送到你这里，压力大小可想而知，并且因为小前端带来的创新产品很可能会带来爆款产品，所以可能也会有瞬间的请求高峰，瞬间的请求浪涌可以瞬间对你的服务造成巨大的冲击，很容易造成系统的崩溃，而且恢复起来代价巨大。这种情况下分布式应用，几乎是必然的选择。

所以说选择分布式应用是一个无奈之举，如果你只是做一个学生管理系统，非要上一分布式应用，我觉得不能显示你多牛X，只是你闲的慌。

关于阿里巴巴的分布式应用，就是外界所熟知的HSF(High Speed Framework，也有人称“好舒服”),目前支撑阿里巴巴近2000个应用。

其前端服务请求应用，中台服务响应应用部署方式(包括调用者、及提供者)与传统应用部署并无区别，都是以war的形式部署在tomcat容器中。但是整套体系里多了如下三个类型的服务器：地址服务器、配置服务器、Diamond 服务器。

地址服务器，主要是用于保存配置服务器、Diamond 服务器地址的，相当于一个入口服务器，通过DNS的方式供各方应用调用。

配置服务器，用于保存服务提供者、服务调用者的ip地址及端口信息。同时起到了动态路由的作用。

Diamond 服务器，主要用于安全管控、服务QPS阀值控制等，也是整个服务调度中的核心模块。服务流程如下图所示：

HSF流程

一个完整的调用流程大致如下，

1、调用者向地址服务器获取配置服务器及diamond服务器地址。

2、向配置服务器获取到服务提供方的地址及端口(同时需要验证调用权限)。

3、向diamond验证调用是否符合安全管控及阀值是否满足要求(一次性请求，如有变更将由diamond服务器主动推送给应用)

4、通过之后就可以向提供方发起请求。

可以看到负载均衡和调用权限是配置服务器控制的，流量控制等是diamond服务器控制的。

通过配置服务器的动态刷新，可以快速的将故障节点剔除，也可以将新的节点迅速的加入到服务列表中，而对前端是无感的。

而通过diamond的阀值控制，可以保证服务提供者不会被流量冲垮，保证服务的可用性。

提到分布式就不得不提微服务。

微服务是这几年很火的一个概念，加上docker的盛行。让人觉得好像必须用上微服务才是分布式一样的感觉，即微服务=分布式。但实际上不是，上面的HSF并不是基于微服务的应用方式，但是依然是很分布式的经典案例。

docker的盛行给人一种错觉，只要是想上分布式，想解决系统面临的性能问题，就一定要搞微服务。不可否认，微服务易于封装，便于移植，而且可以随需创建，本身又十分轻便，不占用系统资源，可以提高系统的利用率，同时与持续集成相结合，可以提升运维效率。这些特性已经被相关人员研究的很透彻了，就不再重复。

但是每枚硬币都有正反面，微服务的反面就是：

1、微服务的服务粒度及边界不容易划分。

到底要把怎么多少业务划分到一个微服务里，才能保证服务划分的比较合理？什么叫做合理，一是服务的划分要保持前瞻性，为以后的扩展留下空间。二是服务粒度不能太细，否则构建出的复杂的微服务架构将非常难以维护，比如你想要修改一个服务的时候，发现要修改A，就必须修改A的依赖B，而B又依赖服务C，然后你在更新的时候就必须按照C、B、A的顺序进行更新，这是在识别到的前提下，如果你漏识别了个别服务就进行了投产，响应在排查问题上也会是个big problem。

粒度划分

2、运维部署及服务的稳定性问题。

微服务相比传统应用将服务的部署难度提升了一个等级，因为服务的数量实在太多了，例如Adrian Cockcroft，Hailo有160个不同服务构成，NetFlix有大约600个服务。每个服务都有多个实例。这就造成许多需要配置、部署、扩展和监控的部分，除此之外，你还需要完成一个服务发现机制，以用来发现与它通讯服务的地址(包括服务器地址和端口)。传统的解决问题办法不能用于解决这么复杂的问题。这就是说成功部署一个微服务应用需要开发者有足够的控制部署方法，并高度自动化。

3、难以测试及判断性能洼地。

微服务的测试需要将所有的服务节点全部启动之后才能进行测试，而且要测试到所有的服务节点的性能，在案例的设置上本省就是一个难题。

我曾亲历一个传统的分布式应用进行了微服务的改造，将这个应用分解为将近100个微服务，并在小范围内进行了试用，应用的各项功能都正常。然后业务部门发送了几十万条营销短信，瞬间吸引了十几万用户来体验新的应用，应用几乎立马就卡死了，维护人员就发现多个节点性能不足，在进行了扩展并重启之后，发现他们依赖的节点也发生了同样的问题，这样反反复复几乎将实例数量增加了一倍才撑住了用户请求。该应用相比传统应用而言，采用微服务架构之后使用的计算资源数量反而增加了一倍多，而且因为应用的卡顿，给用户留下了非常不好的印象，我想并不算一个成功的案例。

总之、软件工程里有个理论叫“没有银弹”，任何应用模式在带来新的机会的时候，都会带来新的挑战。

如果喜欢的请关注我，或者评论我，我会在下期分享共享中心搭建的一些原则。