分布式架构的演进

    系统架构演化历程-使用NoSQL和搜索引擎
 

 

    特征：系统引入NoSQL数据库及搜索引擎。描述：随着业务越来越复杂，对数据存储和检索的需求也越来越复杂，系统需要采用一些非关系型数据库如NoSQL和分数据库查询技术如搜索引擎。应用服务器通过统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

 

    系统架构演化历程-业务拆分
 

 

    特征：系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。描述：为了应对日益复杂的业务场景，通常使用分而治之的手段将整个系统业务分成不同的产品线，应用之间通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。纵向拆分：将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。

 

    系统架构演化历程-分布式服务
 

 

    特征：公共的应用模块被提取出来，部署在分布式服务器上供应用服务器调用。描述：随着业务越拆越小，应用系统整体复杂程度呈指数级上升，由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。

 

 

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

 

    Java分布式应用技术基础
 

 

    分布式服务下的关键技术：消息队列架构
 

 

    消息对列通过消息对象分解系统耦合性，不同子系统处理同一个消息。

 

    分布式服务下的关键技术：消息队列原理
 

 

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

 

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

 

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

 

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

 

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