duboo仿猫眼微服务架构）
微服务入门
传统业务应用
在没有提出微服务的概念时，一个软件应用，往往会将应用所有功能都开发和打包在一起，运行在通用的服务器上，如Tomcat等。此时，大多数应用都在一个JVM中，随着应用的增大，性能会不断下降；业务之间的耦合严重，即使企业内部有规范和约束，但随着业务逻辑复杂度的增加，开发人员的不断流动，整个应用的维护变得越来越难。
传统应用带来的问题：
- 代码臃肿，应用启动时间长；
- 回归测试周期长，修复一个小小bug可能都需要对所有关键业务进行回归测试。
- 应用容错性差，某个小小功能的程序错误可能导致整个系统宕机；
- 伸缩困难，单体应用扩展性能时只能整个应用进行扩展，造成计算资源浪费。
例如使用传统业务进行统一部署时，订单模块、用户模块、影院模块各占三分之一的内存。项目上线时，有的模块并发量小，有的模块并发量大，当并发量大的模块需要扩容时，相对复杂。 - 开发协作困难，一个大型应用系统，可能几十个甚至上百个开发人员，大家都在维护一套代码的话，代码merge复杂度急剧增加。
微服务发展历程
随着互联网应用规模不断扩展，单体应用架构无法满足需求，分布式应用势在必行。
面向服务开发-SOA
SOA（Service-Oriented Architecture）将单一进程的应用做了拆分，形成独立对外提供服务的组件，每个组件通过网络协议对外提供服务。通过这种协议，服务之间可以通过接口进行交互。通过这种架构，将重复的功能抽取为服务，可以提高开发效率，提高系统的可重用性、减少系统中的接口耦合。
常用的SOA实现方式有两种：Web Service和ESB。Web Service通常使用SOAP协议，即用HTTP和HTTPS来传输XML数据。所有的Web Service服务都会注册到Web Service的目录中，每个服务都依赖于这个目录来发现存在的服务。
ESB简称企业服务总线，服务之间的通信与调用都通过总线来完成，ESB作为项目与服务之间通信的桥梁。
缺点
- 系统与服务的界限模糊，不利于开发及维护。
- 虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。
- 取的服务的粒度过大，系统与服务之间耦合性高。
微服务开发
SOA最早的出现是为了解决企业不同系统之间整合的问题，提出服务重用和消息总线。SOA中存在大量的编排，通常通过消息总线来承载业务逻辑，并构建出重量级中心化的中间件。SOA有个很大的问题在于总线，按照这个思想，这些系统总会在某个环节上走向集中，所以去中心化做的很不彻底。
微服务和SOA一脉相承，是一种将业务系统进一步拆分的架构风格。
微服务强调每个单一业务都独立运行，每个单一服务都应该使用更轻量级的机制保持通信。
微服务不强调环境，可以不同语言或数据源，它不关心你用的是Java还是Python，数据库用的是Mysql还是Redis，仅面向自身单一的服务。
特点
- 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责。
- 面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
- 自治：服务间互相独立，互不干扰。每个服务都是一个独立的开发团队。
- 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口
- 数据库分离：每个服务都使用自己的数据源
- 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护。
常见分布式系统框架
接入层
CDN：静态资源缓存
LVS：负载均衡
Nginx：负载和反向代理
Openresty
Nginx+Lua的中间件
处理非业务数据 IP黑名单等应用防火墙 在应用之前做拦截等
应用层
微服务框架
服务治理
自动化运维发布
缓存
热点数据 分布式Session
消息队列
异步 解耦 削峰
持久层
MySQL 文件系统
微服务的选择
Dubbo
Dubbo主要基于Netty和Mina构成，提供高性能、透明的RPC调用。Dubbo可以让开发者像调用本地方法一样调用远程服务，而不需要显式在代码中指定是远程调用。整个过程对开发者透明，Dubbo会自动完成后续的所有操作，例如：负载均衡、路由、协议转换、序列化等。开发者只需要接收对应的调用结果即可。
Dubbo提供了注册中心机制，解耦了消费方和服务方动态发现的问题，并提供高可靠能力，大量采用微内核+富插件设计思想，包括框架自身核心都作为扩展点实现，提供灵活地可扩展能力。
服务提供者在启动时会向注册中心注册自己的元数据（服务IP和端口等），服务消费方在启动时从注册中心订阅服务提供方的元数据，注册中心发生数据变更会推送给订阅的消费者。在获取服务元数据后，服务消费方可以发起RPC调用，在RPC调用前后会向监控中心上报统计信息。
| 分类 | Dubbo的特性 |
|---|---|
| 面向接口代理的高性能RPC调用 | 基于代理的远程调用，服务以接口为粒度 |
| 服务自动注册与发现 | 支持多种注册中心服务，服务实例上下线实时感知 |
| 运行期流量调度 | 内置路由策略，通过配置不同的路由规则，轻松实现灰度发布、同机房优先等功能 |
| 智能负载均衡 | 内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量 |
| 高度可扩展能力 | Protocol、Transport、Serialization被设计为扩展点 |
| 可视化的服务治理与运维 | 随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数 |
SpringCloud
微服务全家桶
Spring Cloud由众多子项目组成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系统及微服务常用的工具，如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局锁、选主、分布式会话和集群状态等，满足了构建微服务所需的所有解决方案。比如使用Spring Cloud Config 可以实现统一配置中心，对配置进行统一管理；使用Spring Cloud Netflix 可以实现Netflix 组件的功能 - 服务发现（Eureka）、智能路由（Zuul）、客户端负载均衡（Ribbon）。
Dubbo类似于Spring Cloud的一个子集，Dubbo功能和文档完善，在国内有很多的成熟用户。Dubbo具有调度、发现、监控、治理等功能，支持相当丰富的服务治理能力。Dubbo架构下，注册中心对等集群，并会缓存服务列表，当服务下线时继续提供发现功能，本身的服务发现结构有很强的可用性与健壮性，足够支持高访问量的网站。
Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC通信。而SpringCloud是基于Http协议+rest接口调用远程过程的通信，相对来说，Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适，至于注重通信速度还是方便灵活性，具体情况具体考虑。
对于类似于电商等同步调用场景多并且能支撑搭建Dubbo 这套比较复杂环境的成本的产品而言，Dubbo 确实是一个可以考虑的选择。
Zero ICE
二进制流
Dubbo
Dubbo总体分为业务层、RPC层、Remote层。Dubbo框架中的分层代表了不同的逻辑实现，他们是一个个组件，这些组件构成了整个Dubbo体系。
| 层次名 | 作用 |
|---|---|
| Service | 业务层。业务代码的接口与实现 |
| config | 配置层。围绕ServiceConfig和ReferenceConfig两个实现类展开，初始化配置信息 |
| proxy | 服务代理层。代理层自动做远程调用并返回结果 |
| register | 注册层。负责Dubbo框架的服务注册与发现 |
| cluster | 集群容错层。远程调用失败时的容错策略；选择具体调用节点时的负载均衡策略；特殊调用路径的路由策略 |
| monitor | 监控层。监控统计调用次数和调用时间等 |
| protocol | 远程调用层。Invoker暴露和引用的主功能入口，管理Invoker的生命周期。 |
| exchange | 信息交换层。建立Request-Response模型，封装请求响应模式，如把同步请求转化为异步请求 |
| transport | 网络传输层。把网络传输（如Netty、Mina）抽象为同一的接口 |
| Serialoze | 序列化层。管理整个框架网络传输时的序列化/反序列化工作 |
