系统架构演变

目录

1. 单体应用架构

2. 垂直应用架构

3. 分布式SOA架构

4. 微服务架构

5. SOA与微服务的关系

6. 分布式核心知识

        6.1 分布式中的远程调用

         6.2 分布式中的CAP原理

1. 单体应用架构

Web应用程序发展的早期，大部分web工程(包含前端页面,web层代码,service层代码,dao层代码)是将所有的功能模块,打包到一起并放在一个web容器中运行。

 优点：

        所有的功能集成在一个项目工程中，项目架构简单，前期开发成本低，周期短，小型项目的首选。

缺点：

        全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。 系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。 技术栈受限。

2. 垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率 

 优点：

        项目架构简单，前期开发成本低，周期短，小型项目的首选。

        通过垂直拆分，原来的单体项目不至于无限扩大不同的项目可采用不同的技术。

缺点：

        全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。

        系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

3. 分布式SOA架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定 的服务中心，使前端应用能更快速的响应多变的市场需求

站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目 的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。 可以发现 SOA 有如下几个特点：分布式、可重用、扩展灵活、松耦合

 优点：

         抽取公共的功能为服务,提高开发效率 对不同的服务进行集群化部署解决系统压力 基于ESB/DUBBO减少系统耦合

缺点：

        抽取服务的粒度较大 服务提供方与调用方接口耦合度较高

4. 微服务架构

 优点：

        通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成本也将大幅度下降。

        微服务遵循单一原则。微服务之间采用Restful等轻量协议传输。

缺点：

        微服务过多，服务治理成本高，不利于系统维护。

        分布式系统开发的技术成本高（容错、分布式事务等）。

5. SOA与微服务的关系

SOA（ Service Oriented Architecture ）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用。

微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。 这些小应用之间通过服务完成交互和集成。 

功能	SOA	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	小型、专注于功能交叉团队
管理	着重中央管理	着重分散管理
目标	确保应用能够交互操作	执行新功能、快速拓展开发团队

6. 分布式核心知识

        6.1 分布式中的远程调用

在微服务架构中，通常存在多个服务之间的远程调用的需求。远程调用通常包含两个部分：序列化和通信协议。常见的序列化协议包括json、xml、hession、protobuf、thrift、text、bytes等，目前主流的远程调用技术有基于HTTP的RESTful接口以及基于TCP的RPC协议。

         RPC（Remote Procedure Call ） 一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC 框架的主要目标就是让远程服务调用更简单、透明。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

        RESTful（Representational State Transfer）以URI的形式进行访问接口。

         6.2 分布式中的CAP原理

现如今，对于多数大型互联网应用，分布式系统（distributed system）正变得越来越重要。分布式系 统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的起点。

分布式系统中的三个特性进行了如下归纳： 

        Consistency（一致性）：数据一致更新，所有数据的变化都是同步的

        Availability（可用性）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求

        Partition tolerance（分区容忍性）：某个节点的故障，并不影响整个系统的运行

选择	说明
CA	放弃分区容错性，加强一致性和可用性，其实就是传统的关系型数据库的选择
AP	放弃一致性（这里说的一致性是强一致性），追求分区容错性和可用性，这是很多分布式 系统设计时的选择，例如很多NoSQL系统就是如此
CP	放弃可用性，追求一致性和分区容错性，基本不会选择，网络问题会直接让整个系统不可用

下一页