1. 系统架构的演变

随着互联网的发展，网站应用的规模不断扩大，常规的应用架构已无法应对，分布式服务架构以及微服务架构势在必行，需要一个治理系统确保架构有条不紊的演进。

1.2 单体应用架构（单击系统）  

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

比如搭建一个电商系统：客户下订单，商品展示，用户管理。这种将所有功能都部署在一个web容器中 运行的系统就叫做单体架构。

 

优点：

        ① 所有的功能集成在一个项目工程中 项目架构简单。

        ② 前期开发成本低，周期短，小型项目的首选。

 

缺点：

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

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

        ③ 只能通过横向服务器扩展。

        ④ 技术栈受限。

1.2 垂直应用架构

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

优点：

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

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

 

缺点：

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

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

1.3 分布式SOA架构

1.3.1 什么是SOA

SOA  全称为  Service-Oriented  Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合 的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。 webservice （RPC框架）

站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，

目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。

通过上面的描述可以发现 SOA  有如下几个特点：分布式、可重用、扩展灵活、松耦合

1.3.2 SOA架构

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

优点：

        ① 抽取公共的功能为服务,提高开发效率 对不同的服务进行集群化部署

        ② 解决系统压力基于ESB/DUBBO减少系统耦合

 

缺点：

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

1.4 微服务架构

优点：

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

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

 

缺点：

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

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

1.5 SOA与微服务的关系

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

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

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

2. 分布式核心知识

2.1 分布式中的远程调用

状态转化（State   Transfer） 访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变 化。互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因 此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State     Transfer）。 客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词： GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

综合上面的解释，我们总结一下什么是RESTful架构：

        ① 每一个URI代表一种资源； 

        ② 客户端和服务器之间，传递这种资源的某种表现层；

        ③ 客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

（2）RPC协议

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

（3）区别与联系

比较项	RESTful	RPC
通讯协议	HTTP	一般使用TCP
性能	略低	较高
灵活度	高	低
应用	微服务架构	SOA架构

2. RPC 框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提 供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节。让调用方感觉就像调用本地函数一样 调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。

2.2 分布式中的CAP原理 

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

CAP理论由 Eric Brewer 在ACM研讨会上提出，而后CAP被奉为分布式领域的重要理论。分布式系统的CAP理论，首先把分布式系统中的三个特性进行了如下归纳：

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

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

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

通过学习CAP理论，我们得知任何分布式系统只可同时满足二点，没法三者兼顾，既然一个分布 式系统无法同时满足一致性、可用性、分区容错性三个特点，所以我们就需要抛弃一样：

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

需要明确一点的是，在一个分布式系统当中，分区容忍性和可用性是最基本的需求，所以在分布是系统 中，我们的系统最当关注的就是A（可用性）P（容忍性），通过补偿的机制寻求数据的一致性。

2.3 常见微服务框架

2.3.1 SpringCloud

SpringCloud 是一系列框架的有序集合。它利用Spring   Boot的开发便利性巧妙地简化了分布式系统基 础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 Spring   Boot的开发风格做到一键启动和部署。Spring   Cloud并没有重复制造轮子，它只是将目前各家 公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring     Boot风格进行再封装屏蔽掉 了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

2.3.2 ServiceComb

 Apache ServiceComb 是业界第一个Apache微服务顶级项目， 是一个开源微服务解决方案,致力于帮助 企业、用户和开发者将企业应用轻松微服务化上云，并实现对微服务应用的高效运维管理。其提供一站 式开源微服务解决方案，融合SDK框架级、0侵入ServiceMesh场景并支持多语言。

2.3.3 ZeroC ICE

Zero CIceGrid 是ZeroC公司的杰作，继承了CORBA的血统，是新一代的面向对象的分布式系统中间 件。作为一种微服务架构，它基于RPC框架发展而来，具有良好的性能与分布式能力。