架构的演进

1.1单体架构

将所有业务场景的表示层、业务逻辑层和数据访问层放在一个工程中，最终经过编译、打包，部署在一台服务器上。

◆ 1.1.1单体架构的优点

1）部署简单: 由于是完整的结构体，可以直接部署在一个服务器上即可。

2）技术单一: 项目不需要复杂的技术栈，往往一套熟悉的技术栈就可以完成开发。

3）用人成本低: 单个程序员可以完成业务接口到数据库的整个流程。

◆ 1.1.2单体架构的缺点

1）系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长；

2）系统错误隔离性差、可用性差，任何一个模块的错误均可能造成整个系统的宕机；

3）可伸缩性差：系统的扩容只能只对这个应用进行扩容，不能做到对某个功能点进行扩容；

4）线上问题修复周期长：任何一个线上问题修复需要对整个应用系统进行全面升级。

1.2 SOA架构（面向服务架构）

SOA，面向服务架构。SOA中心化的实现方式就是ESB（企业服务总线），依靠ESB，集成不同系统、不同协议的服务，连接各个服务节点，做消息的转化解释和路由工作，让不同的服务互联互通；

1.2.1 RPC远程过程调用

RPC，Remote Procedure Call，即远程过程调用，建立在Socket之上的，在一台机器上运行的主程序，可以调用另一台机器上准备好的子程序。

RPC框架：

国内：

Dubbo，阿里巴巴，http://dubbo.I/O/；

Motan ，新浪微博，https://github.com/weibocom/motan；

Dubbox，当当，https://github.com/dangdangdotcom/dubbox；

Rpcx，基于 Golang 的https://github.com/smallnest/rpcx；

国外：

Thrift，facebook，https://thrift.apache.org；

gRPC，Google，http://www.grpc.I/O；

Avro，hadoop，https://avro.apache.org；

阿里巴巴的Dubbo、HSF，Spring的Spring Cloud等，底层基于NIO；

1.2.2 RMI远程方法调用

让在客户端Java虚拟机上的对象像调用本地对象一样调用服务端java 虚拟机中的对象上的方法。

使用代表：EJB。

远程方法调用步骤：

客户调用客户端辅助对象stub上的方法

客户端辅助对象stub打包调用信息（变量、方法名），通过网络发送给服务端辅助对象skeleton；

服务端辅助对象skeleton将客户端辅助对象发送来的信息解包，找出真正被调用的方法以及该方法所在对象；

调用真正服务对象上的真正方法，并将结果返回给服务端辅助对象skeleton；

服务端辅助对象将结果打包，发送给客户端辅助对象stub；

客户端辅助对象将返回值解包，返回给调用者。

客户获得返回值。

Java1.2+内置的RMI，底层基于BIO；

1.2.3 区别

1、RMI 只能在 Java 语言中使用，可以把 RMI 看作面向对象的 Java RPC；

2、RPC是一种编程模型。

1.3 微服务架构

微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想。

◆ 1.3.1微服务的特征

通过服务实现组件化

按业务能力来划分服务和开发团队

去中心化（此处中心化指的是去中心化数据管理和去中心化服务治理）

单一职责：微服务中每个服务都对应唯一的业务能力

微：微服务的拆分粒度很小，例如一个用户管理可以作为一个服务。每个服务很小，但是五脏俱全

面向服务：服务对外暴露Rest风格服务接口API，不限制

自治：

团队独立

技术独立：因为面向服务，不关心使用技术/语音，提供Restful接口即可

前后端分离：提供统一的Rest接口，后端不再为PC、移动端单独开发不同的接口

数据库分离：每个服务都使用自己的数据库，很少情况出现多数据源的情况

部署独立：每个服务都是独立的组件、可复用、可替换、低耦合，易维护。

◆ 1.3.2微服务的优点

拆分业务，把整体大项目分割成不同小项目运行在不同进程或者机器上实现数据隔离；

技术栈，每个服务可以由不同的团队或者开发者进行开发，外部调用人员不需要操心具体怎么实现的，只需要类似调用自己方法一样或者接口一样按照服务提供者给出来的参数传递即可；

独立部署，每一个服务独立部署，部署一个服务不会影响整体项目，如果部署失败最多是这个服务的功能缺失，并不影响其他功能的使用；

弹性。

按需部署，针对不同的需求可以给不同的服务自由扩展服务器，根据服务的规模部署满足需求的实例；

局部修改，当一个服务有新需求或者其他修改，不需要修改整体项目只要管好自己的服务就好；

◆ 1.3.3微服务的缺点

运维，微服务由于把业务拆分得细，有可能部署在不同机器上，因此对于运维人员的管理来说，这部分的成本会加大；

接口调整，微服务之间通过接口进行通信。如果修改某个微服务的API，可能所有使用了该接口的微服务都需要做调整；

运维，微服务由于把业务拆分得细，有可能部署在不同机器上，因此对于运维人员的管理来说，这部分的成本会加大；

分布式，由于会把不同服务部署在不同机器上，那么对于这些服务的调用、容错、网络延迟、分布式事务等等都是一个很大的挑战，当然微服务不一定全部都是部署在不同服务器上

1.4 SOA架构和微服务架构的差别

微服务不再强调传统SOA架构里面比较重的 ESB 企业服务总线，同时 SOA 的思想进入到单个业务系统内部实现真正的组件化。

Docker 容器技术的出现，为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似 Node或者 Spring Boot 等技术跑在自己的进程中。

SOA 注重的是系统集成方面，而微服务关注的是完全分离。

微服务机构和SOA架构都是对系统进行拆分；

微服务架构基于SOA架构；

管理方面：SOA着重中央管理（ESB），微服务注重分散管理；

1.5 SpringCloud微服务组件

SpringCoud中文网：https://www.springcloud.cc/；

注册中心：Zookeeper、Eureka、Nacos、Consul。

API服务网关：Nginx、zuul、gateway、Kong、Traefik等

功能：统一入口、路由功能、负载均衡、统一鉴权、协议转换（统一服务）、指标监控、限流熔断、黑白名单、统一日志等。

API网关	所属公司	开发语言	优点	缺点
Nginx	Nginx inc	C/Lua	高性能、成熟稳固	门槛高，偏运维，可编程弱
Zuul1.x/2	Netflix/Pivotal	Java	成熟，简略门槛低	性能个别，可编程个别
Gateway	Pivotal	Java	异步、Netty、配置灵便	晚期产品
Kong	Kong inc	OpenResty/Lua	高性能、可编程API	门槛较高
Traefik	Containous	Golang	云原生、可编程API/对接各种服务发现	生产案例不太多