分布式架构的演进过程

一、什么是分布式架构

分布式系统（distributed system） 是建立在网络之上的软件系统。
内聚性：是指每一个数据库分布节点高度自治，有本地的数据库管理系统。
透明性：是指每一个数据库分布节点对用户的应用来说都是透明的，看不出是本地还是远程。在分布式数据系统中，用户感觉不数据是分布的，即用户不须知道关系是否分割，有无副本，数据存在于那个站点以及事物在哪个站点上执行。
简单来说：在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。　

分布式系统作为一个整体对用户提供服务，而整个系统的内部的协作对用户来说是透明的，用户就像是指使用一个mysql 一样。
如：分布式mysql中间件 mycat ,来处理大并发大数据量的构架。

二、分布式架构的演进

1、初始阶段架构

特征：应用程序，数据库，文件等所有资源都放在一台服务器上。

2、应用服务和数据服务以及文件服务分离

说明：初始架构好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver。

特征：应用程序、数据库、文件分别部署在独立的资源上。

3、使用缓存改善性能

说明：系统访问特点遵循二八定律，即80%的业务访问集中在20%的数据上。缓存分为本地缓存和远程分布式缓存，本地缓存访问速度更快但缓存数据量有限，同时存在与应用程序争用内存的情况。

特征：数据库中访问较集中的一小部分数据存储在缓存服务器中，减少数据库的访问次数，降低数据库的访问压力。

4、使用应用服务器集群

说明：在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了。突然有一天，发现系统的访问又开始有变慢的趋势了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来是请求数太高导致需要排队等待，响应速度变慢。

特征：多台服务器通过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。

描述：使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，提升系统的并发处理能力，使得服务器的负载压力不再成为整个系统的瓶颈。

5、数据库读写分离

说明：享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入更新这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢。

特征：随着一个网站的业务不断扩展，数据不断增加，数据库的压力也会越来越大，对数据库或者SQL的基本优化可能达不到最终的效果，我们可以采用读写分离的策 略来改变现状。读写分离现在被大量应用于很多大型网站，基本的原理是让主数据库处理事务性查询，而从数据库处理SELECT查询。数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库。 当然，主服务器也可以提供查询服务，使用读写分离最大的作用无非是缓解服务器压力。

描述：读写分离增加了冗余，增加了机器的处理能力，适用于读远大于写场景的应用，可以确保写的服务器压力更小，而读又可以接受点时间上的延迟。

6、反向代理和CDN加速

特征：采用CDN和反向代理加快系统的访问速度。

描述：为了应付复杂的网络环境和不同地区用户的访问，通过CDN和反向代理加快用户访问的速度，同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。

7、分布式文件系统和分布式数据库

说明：随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作。

特征：数据库采用分布式数据库，文件系统采用分布式文件系统。

描述：任何强大的单一服务器都满足不了大型系统持续增长的业务需求，数据库读写分离随着业务的发展最终也将无法满足需求，需要使用分布式数据库及分布式文件系统来支撑。

分布式数据库（分库分表）是系统数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。

8、使用NoSQL和搜索引擎

特征：系统引入NoSQL数据库及搜索引擎。

描述：随着业务越来越复杂，对数据存储和检索的需求也越来越复杂，系统需要采用一些非关系型数据库如NoSQL和分数据库查询技术如搜索引擎。　　　　　

应用服务器通过统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

9、根据业务拆分应用

特征：系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。

描述：为了应对日益复杂的业务场景，通常使用分而治之的手段将整个系统业务分成不同的产品线，应用之间通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

纵向拆分：将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统，纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。

横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务，横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。

10、分布式服务

特征：公共的应用模块被提取出来，部署在分布式服务器上供应用服务器调用，例如消息队列服务可集成为中间件应用。

描述：随着业务越拆越小，应用系统整体复杂程度呈指数级上升，由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。

三、分布式服务应用会面临哪些问题

1. 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
2. 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
3. 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
4. 服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？
5. 一个服务有多个业务消费者，如何确保服务质量？
6. 随着服务的不停升级，总有些意想不到的事发生，比如cache写错了导致内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面？服务是否可以功能降级？或者资源劣化？

总结：分布式系统并非灵丹妙药，解决问题的关键还是看你对问题本身的了解。通常我们需要使用分布式的常见理由是：为了性能扩展——系统负载高，单台机器无法承载，希望通过使用多台机器来提高系统的负载能力为了增强可靠性——软件不是完美的，网络不是完美的，甚至机器本身也不可能是完美的，随时可能会出错，为了避免故障，需要将业务分散开保留一定的冗余度在以提供 Service 为主的服务端软件开发过程中常常遇到这些问题。

Java分布式应用技术基础

分布式服务下的关键技术：消息队列原理
消息对列通过消息对象分解系统耦合性，不同子系统处理同一个消息。

分布式服务下的关键技术：服务框架架构

服务框架通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用
服务框架是一个点对点模型
服务框架面向同构系统
适合：移动应用、互联网应用、外部系统

分布式服务下的关键技术：服务总线架构

服务总线同服务框架一样，均是通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用
服务总线是一个总线式的模型
服务总线面向同构、异构系统
适合：内部系统

企业数据总线(ESB)和服务注册管理的区别

1. ESB就是企业数据总线的意思，他的核心功能就是兼容各种协议接口，可以将数据在各种协议之间进行流转，并且可以针对数据格式进行编排转换。格式转换、协议转换、代理、编排、安全控制、监控、不支持高并发，类似于路由器维护着一张路由表进行路由转发。代表性的项目有：JBOSS ESB、Mule、Camel 以及一些其他的esb项目。
2. 服务注册就是将所有的服务接口，注册到一个中心的分布式服务集群上（你可以考虑成Apache的zooKeeper服务实现的效果）。各个业务系统直接访问分布式服务查找需要调用的接口位置，进而调用，注册目录服务、监控、负载均衡、安全控制、分布式强健壮、适用于高并发。代表性开源项目有：阿里的dubbo，淘宝的HSF。
3. ESB一般采用集中式转发请求，适合大量异构系统集成，并且压力不大的情况。集中式转发是有优势的，比如调用方用HTTP协议，提供方用RMI协议，转发就可以转换协议，对双方都透明。另外，在总线上还可以执行流程引擎，做服务编排，比如A和B两个服务经常一起调，就可以编排成服务C，而不用再单独启一个服务去做。还有安全，流控，做起来也更方便。
4. 服务注册管理采用的是分布式调用，注册中心只记录地址信息，然后直连调用，适合并发及压力比较大的情况。对于网站应用，大多是垂直业务，直接从数据库拉数据展示。

综述：两类开源项目侧重点不同，ESB侧重任务的编排，性能问题可通过异构的方式来进行规避，无法支持特别大的并发。服务注册侧重服务的治理，将各个服务颗粒化，各个子业务系统在程序逻辑上完成业务的编排。但是比较适用于较大的并发量，能保证单点的失败不影响整个系统的业务调用，因为业务接口都是在各个提供服务的子系统中。

---

本文转载自知乎：https://www.zhihu.com/question/22764869/answer/31277656