分布式系统架构

系统架构的演变

单体应用架构
优点：开发简单，适用于小型应用
缺点：不易拓展，维护，代码耦合

垂直应用架构
优点：解决高并发问题；针对不同的模块优化；方便水平扩展，容错
缺点：系统间相互独立，不知道如何进行调用，重复开发工作

SOA
Service Oriented Architecture ,即面向服务的架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件（服务）进行分布式部署，组合和使用，一个服务通常以独立的形式存在于操作系统进程中。
站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为调用的业务服务，实现业务逻辑的快速复用
特点：分布式、可重用、扩展灵活、松耦合
优点：
抽取公共的功能为服务，提高开发效率；对不同的服务进行集群化部署解决系统压力；基于ESB、DUBBO减少系统耦合
缺点：
抽取服务的粒度较大
服务提供方和服务消费方接口耦合度较高

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

SOA和微服务的关系

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

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

远程调用技术

流行的调用技术：RPC，HTTP

RPC

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

HTTP

RESTful接口
REST，即Representational State Transfer，如果一个架构符合REST原则，就称它为RESTful架构。

两者区别与联系

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

1. HTTP相对更规范，更标准，更通用，无论哪种语言都支持http协议，如果你是对外开放API，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，现在开源中间件，基本最先支持的几个协议都包含RESTful
2. RPC框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提供方的研发效率，屏蔽跨进程调用服务的各类复杂细节，让调用方感觉就像调用本地函数一样调用远端函数，让服务提供方感觉就像实现一个本地函数一样来实现服务。

CAP理论

CAP理论由Eric Brewer在ACM研讨会上提出，而后CAP被奉为分布式领域的重要理论。
分布式系统的最大难点，就是各个节点的状态如何同步，CAP定理是这方面的基本定理，也是理解分布式系统的起点。

A:可用性 -----保持服务可用，多节点
C:一致性 -----多节点数据一致
P:分区容忍性 -----是否可以将数据存放到多个地方

不可能同时满足C，A，P
AP：可以短暂允许数据的不一致，NoSql数据库
CP：放弃可用性，Zookeeper就，假如上面是三台zk，客户端写数据到节点1，然后由节点1同步给节点2,3，在同步的这段时间内，服务是不可用的。
CA：放弃分区容忍，物理数据库