分布式SOA架构和微服务架构

分布式SOA架构：
　　什么是SOA
　　　　SOA 全称为 Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。
　　　　一个服务通常以独立的形式存在于操作系统进程中。
　　　　站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，

　　　　目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。
　　　　通过上面的描述可以发现 SOA 有如下几个特点：分布式、可重用、扩展灵活、松耦合
　　SOA架构
　　　　当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求
　　　　

　　优点：
　　　　抽取公共的功能为服务,提高开发效率
　　　　对不同的服务进行集群化部署解决系统压力
　　　　基于ESB/DUBBO减少系统耦合
　　缺点：
　　　　抽取服务的粒度较大
　　　　服务提供方与调用方接口耦合度较高

 微服务架构：

　　

　　优点：
　　　　通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成本也将大幅度下降
　　　　微服务遵循单一原则。微服务之间采用Restful等轻量协议传输。
　　缺点：
　　　　微服务过多，服务治理成本高，不利于系统维护。
　　　　分布式系统开发的技术成本高（容错、分布式事务等）。

SOA与微服务的关系：

　　SOA（ Service Oriented Architecture ）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。
　　一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。
　　微服务架构其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，
　　原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
　　

分布式中的远程调用：

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

　　　　REST，即Representational State Transfer的缩写，如果一个架构符合REST原则，就称它为RESTful架构。
　　　　资源（Resources）
　　　　　　所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。
　　　　　　你可以用一个URI（统一资源定位符）指向它，
　　　　　　每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。
　　　　　　REST的名称"表现层状态转化"中，省略了主语。"表现层"其实指的是"资源"（Resources）的"表现层"。
　　　　表现层（Representation）
　　　　　　"资源"是一种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表现层"（Representation）。
　　　　　　比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；
　　　　　　图片可以用JPG格式表现，也可以用PNG格式表现。URI只代表资源的实体，不代表它的形式。
　　　　　　严格地说，有些网址最后的".html"后缀名是不必要的，因为这个后缀名表示格式，属于"表现层"范畴，而URI应该只代表"资源"的位置。

　　　　状态转化（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）区别与联系

　　　　

　　　　1、HTTP相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如开放平台，外部的编程语言多种多样，
　　　　　　你无法拒绝对每种语言的支持，现在开源中间件，基本最先支持的几个协议都包含RESTful。

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

　　现如今，对于多数大型互联网应用，分布式系统（distributed system）正变得越来越重要。分布式系统的最大难点，就是各个节点的状态如何同步。
　　CAP 定理是这方面的基本定理，也是理解分布式系统的起点。
　　CAP理论由 Eric Brewer 在ACM研讨会上提出，而后CAP被奉为分布式领域的重要理论。分布式系统的CAP理论，首先把分布式系统中的三个特性进行了如下归纳：

　　　　Consistency（一致性）：数据一致更新，所有数据的变化都是同步的
　　　　Availability（可用性）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求（多节点）
　　　　Partition tolerance（分区容错性）：某个节点的故障，并不影响整个系统的运行（可以将数据存到多个地方）
　　通过学习CAP理论，我们得知任何分布式系统只可同时满足二点，没法三者兼顾，
　　既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点，所以我们就需要抛弃一样：

 　　

 　　

 　　对于分布式互联网应用而言，必须保证P，所以要么满足AP模型、要么满足CP模型