软件架构的进化

 软件架构是在软件的内部，经过综合各种因素的考量、权衡，选择特定的技术，将系统划分成不同的部分并使这些部分相互分工，彼此写作，为用户提高需要的价值。

因素考量

• 业务需求
• 技术栈
• 成本
• 可扩展性
• 组织架构（分工）
• 可维护性

架构进化史
  一层架构 -> MVC -> Dubbo

单体架构
 功能、业务集中在一个发布包里，部署运行在同一个进程中。

• 易于开发
• 易于测试
• 易于部署
• 易于水平伸缩（新建服务器、配置好环境、复制软件包）

 致命的硬伤：

• 代码膨胀、难以维护。（分析、定位、修复、成本高）
• 构建、部署成本大
• 新人上手困难
• 创新困难
• 可扩展性差

微服务间如何通讯

通讯模式角度考虑

从通讯协议角度考虑

• REST API
• RPC（dubbo、dubbox、motan、grpc、thrift）
• MQ （发布订阅模式）

如何选择RPC框架

• I/O、线程调度模型（NIO、BIO、长连接、短连接、单线程、多线程、线程调度算法的性能如何）
• 序列化与反序列化方式（可读XML、JSON；二进制序列化）
• 多语言支持
• 服务治理（服务发现、服务监控等…）

流行的RPC框架

• Dubbo/Dubbox
• Motan
• Thrift
• Grpc

服务发现

传统服务的服务发现

微服务
客户端发现

服务端发现

服务编排（微服务的部署、更新、扩缩容）

流行的服务编排工具

• Mesos
• Docker Swarm
• Kubernetes

SpringBoot与微服务关键

 化繁为简，Springboot是Java开发微服务的润滑剂。使用SpringBoot开发微服务恰巧应对了微服务本身所具体的特征。

• 独立运行：java - jar xxx.jar
• 内嵌web服务器
• 简化配置
• 准生产的应用监控

SpringCloud与微服务

 简化Java的分布式系统的开发。
 一系列框架的集合。
 Springboot封装，屏蔽复杂性和实现原理。

SpringCloud & SpringBoot

 SpringBoot意在简化，是一种开发、配置风格。
 SpringCloud意在简化分布式，是功能和集合，风格的统一。微服务架构的一站式解决方案，以SpringBoot的风格去简化。

SpringCloud与微服务

 SpringCloud是Java的一套微服务解决方案。但并不完整，因为它侧重于功能开发，并没有提供资源管理、自动化部署等等…… 它只是Dev，而没有Ops。
 SpringCloud做微服务，最终的产出是Image镜像而已。如何合理的分配机器资源，运行镜像，这些功能SpringCloud并没有提供。需要服务编排框架：K8S等…

微服务定义

 基于有界上下⽂的（每个团队可以维护自己的数据源，而非集中式的数据源），松散耦合的⾯向服务的架构。

• 一组小的服务：对于“小”的定义是没有明确规范的，基本一个服务可以让开发人员在大脑中容易理解，就可以称为微服务。
• 独立的进程：微服务可以部署在容器中，容器可以部署在物理机上，以进程方式运行，以进程的方式去横向扩展微服务。
• 轻量级通信：No SOAP，比如：HTTP JSON。
• 基于业务能力：用户服务、登录服务、商品服务。
• 独立部署：微服务的拆分使得每个团队维护自己的服务，演化、迭代、开发自己的微服务，团队之间不需要太多的协调，可以独立部署自己的微服务，大幅度的提高了对业务需求的迭代速度。
• 无集中式管理：每个团队可以根据业务的特点，选最适合该业务的技术栈，每个团队均可采用不同的存储机制。

参考Martin Fowler文章。

微服务的利与弊

优势

• 强模块化边界（类 => 类库 => 微服务）
• 可独立部署（不需要多个团队之间协同）
• 技术多样性（每个团队可以根据业务的特点，选最适合该业务的技术栈）

弊端

• 分布式复杂性（多个微服务之间协作，每个团队很难清晰地理解整个系统是如何工作的）
• 最终一致性（每个团队都有数据拷贝）
• 运维复杂性
• 测试复杂性

康威法则

设计系统的组织，其产⽣的架构设计等价于组织间的沟通结构。

• 单块应用架构与多团队之间不匹配：应用无法反应组织架构，随之带来的问题就是沟通成本很高、交付效率很低、有时甚至会产生摩擦。

微服务架构的适用性

单块优先原则

直接使用微服务体系的会存在以下问题：

• 前期的基础设施投入较高、复杂性较高。
• 初期对业务（问题领域）并没有清晰的理解，很难把控如何拆分服务、如何划分服务的边界。

单块优先原则的优势：

• 随着业务发展，对业务领域越来越清晰，进而拆分服务，逐渐拆分、逐步细化，最后形成微服务架构，安全性相对较高。

微服务组织架构

• 微服务组织架构可以更快的响应业务员需求。

微服务中台战略

 大中台、小前台

服务分层

微服务技术架构体系

微服务的服务发现机制

独⽴LB模式

 传统模式，有独立LB（Nginx、F5），当Provider上线以后向运维申请DNS域名，运维人员会将此域名配置到LB中，Provider一般会部署多份，以便LB实现负载均衡功能。
 缺点：服务配置、域名配置、LB配置需要运维介入，集中的LB可能会成为单点故障，Consumer去调用后台服务的时候必须穿透LB，这势必会增加性能开销。

进程内LB模式

 将LB的功能集成在Consumer内，Provider将自己信息注册在Registry，并维持心跳宣告自己的存活，Consumer定期去Registry拉取最新的注册信息列表。
 优势：不需要经过中间层，直接访问Provider，避免了不必要的性能开销，也不存在LB单点故障的问题。
 缺点：在多语言环境中必须为每一个消费者开发一个consumer，升级成本和多语言支持成本较高。

主机独⽴进程LB模式

 在每台主机上部署一个独立的LB进程，既没有独立LB的单点故障和性能问题，也可以支持多语言，对于consumer来说更加友好，比较灵活的介入，不需要为每种语言开发客户端。
 缺点：运维成本较高，每台主机上需要部署一个LB进程。

微服务API网关

• 屏蔽内部服务细节，对外提供统一的接口。
• 反向路由：将外部请求匹配到内部的具体服务的调用。
• 安全认证：鉴权。
• 限流熔断
• 日志监控

微服务路由发现体系

微服务配置中心

• pull拉：有点是一定可以拉取的到。
• push推：实时性更强。

携程开源Apollo设计简图

微服务通信方式 RPC VS REST

微服务框架的治理

微服务的监控分层和监控架构

微服务调用链监控选型

Trace调⽤链监控原理

调用链监控选型

微服务的限流熔断是如何工作的

• 熔断：切断故障服务，阻止因服务之间级联依赖引起的雪崩效应。
• 隔离：将硬件资源按一定比例分配给指定服务，防止某一服务占用过高的硬件资源，早期其他服务处于饥饿状态，从而引发出由一个服务导致其他服务不可用。
• 限流：单位时间内只允许处理一定数量的请求。
• 降级：系统后台已经无法提供足够的支撑能力，需要有一种降级能力让服务的负载不会再进一步的恶化，或是以一种简化的方式处理请求。

Netflix Hystrix 断路器原理

 当使用Hystrix熔断组件之后，服务间的通信调用封装在Hystrix Command之内，封装之后的调用就具有：熔断、限流、隔离、降级的功能。

容器部署技术、持续交付流水线、常见的发布模式

• 容器镜像解决了环境一致性的问题。
• 容器镜像解决了不同服务部署的差异。

容器集群调度平台Mesos、基于容器的发布体系

容器集群调度平台Mesos

基于容器的发布体系