【万字长文、多图】微服务架构学习笔记

这是一份是我在极客时间学习《微服务架构核心20讲》时作的笔记。

大纲

1.什么是微服务架构？
2.架构师如何权衡微服务的利弊？
3.康威法则和微服务给架构师怎样的启示
4.企业应该在何时开始考虑引入微服务
5.怎么的组织架构更适合微服务？
6.如何理解阿里巴巴提出的微服务中台战略
7.如何给出一个清晰简洁的服务分层方式？
8.微服务整体技术架构是怎样设计的
9.微服务最经典的三种服务发现机制
10.微服务 API 服务网关（一）“原理”
11.微服务 API 服务网关（二）“开源网关 Zuul”
12.跟 Netflix 学习微服务路由发现体系
13.集中式配置中心的做用和原理
14.微服务通信方式 RPC vs. REST
15.微服务架构须要考虑哪些治理环节
16.微服务监控系统分层和监控架构
17.微服务的调用链监控该如何选择
18.微服务的容错限流是如何工做的
19.Docker 容器部署技术 & 持续交付流水线
20.容器集群调度和基于容器的发布体系

---

什么是微服务架构？

1. 微服务主张将单体应用拆成小的独立服务
2. 微服务运行在独立的进程中，以进程的方式来横向扩展。（Java 运行在 Tomcat 中，NodeJS，容器等）
3. 轻量级的通讯机制（HTTP）
4. 基于业务能力（SOA）来构建
5. 独立部署，每一个团队维护本身的部署
6. 无集中式的管理，原来模式会有架构团队来规划标准：统一技术栈、统一存储方式。而微服务主张每一个团队根据本身的的业务须要选择本身对擅长的、最能解决当前技术问题的技术栈，甚至采用不用的存储方式。

Netflix - 微服务定义：Loosely coupled (松耦合), service oriented architecture (面向服务架构 - SOA) with bounded context(有界上下文或局部状态)。

架构师如何权衡微服务的利弊？

微服务优点：

1. 强模块化边界，从类方式 -> 组件（类库）-> 以服务的方式作模块化（每一个团队独立的开发和维护本身的服务，开发完其余团队能够直接调用这个服务，而不须要像 jar 包同样去分享）
2. 可独立部署，不要引入其余团队来一块儿部署
3. 技术多样性，分散式治理。不是越多越好（技术复杂性）

微服务带来的挑战：

1. 分布式复杂性，单块应用由一个团队就能搞定。微服务化变成分布式系统，会涉及到几10、上百个服务，服务之间相互沟通合做使得系统会变得很是复杂，通常的开发人员或团队都不能清晰的了解整个系统如何工做的
2. 最终一致性，每一个团队有本身的数据存贮，例如：A 团队有订单数据、B 团队也有订单数据，当A 团队改变订单数据时，须要同步到有相似概念的团队，这就涉及到数据一致性的问题
3. 运维复杂性，运维的是一个分布式系统，对监控、容量规划、可靠性、稳定性提出了很是大的挑战
4. 测试复杂性，须要多个团队联合作集成测试

康威法则和微服务给架构师怎样的启示

康威法则：

“Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.”

设计系统的组织，其产生的设计和架构，等价组织的组织架构。

初期团队规模、业务量不大、系统比较简单，主要尝试业务模式能不能起来。随着业务增加、团队规模变大（从一个团队扩大到多个团队），这时候若是系统架构仍然是单块应用就会和多团队产生不匹配的状况（违反了康威法则，即单块应用架构没有反应组织架构）就会出现矛盾、协调成本变高、交付效率变低。

微服务是一种解决手段，将单块应用拆分红若干个微服务（图：组织内部有 3 个团队，把单块架构拆分红 S一、S二、S3 3 个服务，每一个团队负责维护本身的服务。符合康威法则）

扩展：每一个架构师都应该研究下康威定律

企业应该在何时开始考虑引入微服务

初期业务复杂性不高，开发的应用系统主要是验证商务模式。这个时候建议采用单块应用。不推荐微服务，由于微服务前期有基础设施要求，使得生产力变低。

随着应用变得成功、用户变多、系统复杂性变得愈来愈高，若是仍然使用单块应用就会违背康威法则，使得生产力会随着系统复杂性而下降，这时候就要考虑使用微服务。

考虑使用微服务的点（图中交叉点），我的经验：团队接近百人研发时应该考虑采用微服务架构。

如何选择?

1. 开始就走微服务架构
2. 单块优先

不推荐方案 1：由于一开始的时候对问题领域并非很理解，很难把控怎么来拆分这个服务、划分服务边界。另外有可能花了不少精力开发一套微服务，可是这个应用并不被客户接受（应用没有被市场验证，可能会失败）

推荐： 单块优先，随着业务推动，架构师会对业务领域有愈来愈清晰的了解，这个时候若是单块应用不能知足业务发展需求了，研发效率开始降低（到了交叉点）。须要将某些功能点拆分出来，后续陆陆续续随着业务团队变大能够将其余功能点陆续拆分出来，最后变成一个微服务架构。

怎么的组织架构更适合微服务？

横坐标： 业务价值流交付过程（研发 -> 上线 -> 运维）

纵坐标： 业务能力，不一样的业务线（业务团队）

传统企业： 团队划分是严格按照职能的（独立职能部门），当有项目来的时候会从每一个团队抽调一些人来组成交付团队，当项目完成后这些人会回到各自的职能团队。

这个团队的劣质：

1. 沟通成本比较大（团队沟通）
2. 反馈慢、周期长

基于微服务跨职能的组织模式：每一个团队跨职能既有产品专家、用户体验专家、研发、测试专家，整个造成一个端到端的闭环。这些人围绕在微服务周围进行开发、测试和交付、不会由于项目结束而解散。

DBA、运维也以产品的方式来交付平台产品（将计算、网络存储、持续交付的能力封装在一个平台内），对外提供 API 来支持不一样的业务线快速的交付、迭代。

端到端控制权： 团队内部人要负责：架构、设计、开发、评审、测试、发布、运行和支持。

团队规模：根据亚马逊的两个披萨原则 – 12我的左右（2 个披萨能搞定） 谁开发、谁就要去构建、去负责运行

微服务架构本质上是组织架构的重组 – Netflix 前架构师 Andrew

---

如何理解阿里巴巴提出的微服务中台战略

现代技术体系分四层：

1. IaaS层：基础设施即服务：计算、存储、网络、监控等由基础运维团队来负责，提供底层基础设施
2. PaaS层：平台即服务：应用监控、持续交付、服务框架、后台服务（大数据、AI）
3. 核心业务层：
4. 应用层
5. 渠道（第三方接入）

阿里巴巴提出大中台（技术中台 + 业务中台），小前台战略（前端业务更小、更灵活，能根据市场的变化、业务的需求不断的演化）从而赋能业务的持续创新，产生各类业务模式、快速响应市场需求。

PaaS 是微服务基础设施层，核心业务层是公司的核心领域能力把它微服务化、抽象化沉淀下来的核心能力，这层能力依赖下一层的 PaaS 云平台、大数据及AI，同时向上支撑不一样的业务线去交付业务应用。

如何给出一个清晰简洁的服务分层方式？

分红两层（不一样公司有本身的分层，有的3、四层，有的只有一层：统称服务或微服务）

1. 基础服务：支撑性服务，如电商网站的商品服务、用户服务、购物车服务。都比较基础性、原子性
2. 聚合服务：因为有不一样的外部接入端，会对服务作适当的适配、聚合和裁剪的工做

微服务整体技术架构是怎样设计的

1. 接入层：外部、内部流量接入
2. 网关层：流量接入后进入网关层，网关层在微服务体系中占有很是重要的地位，主要作反向路由、限流熔断、安全等跨横切面的功能
3. 业务服务层：分为聚合层和基础层
4. 支撑服务：微服务须要支撑体系来支撑它，例如：服务的注册发现、集中化配置、容错限流、认证受权、日志聚合、监控告警、后台服务（MQ、缓存、Job、数据访问）
5. 平台服务层：发布系统、集群资源调度、镜像治理、IAM（权限管控）
6. 基础设施：主要有运维团队维护

微服务最经典的三种服务发现机制

1. 传统基于LB (负载均衡)的模式
2. 进程内LB 模式
3. 主机独立LB 模式

方式一：服务提供商上线后会向运维申请一个域名，而后运维配置负载均衡器。当用户访问域名时会域名解析到负载均衡器，负载均衡器进而指向到后台服务器（多份）

优势：广泛的作法、比较简单；消费者接入的成本比较低 缺点：服务的配置、域名的配置都须要运维的介入；集中的LB 可能会是一个单点，若是集中式LB 挂掉会影响到整个服务没法访问；性能损失，当消费者调用后台服务时必须穿透LB ，会有性能开销。

方式二：将LB 功能移动到应用的进程内，服务提供商会自动经过注册方式注册到服务注册表，并按期发送心跳。服务消费经过客户端（带有服务发现和负载均衡功能）LB 调用后台服务，而且LB会按期同步服务注册表中的服务信息。

优势： 没有集中式的LB，性能会好，不存在单点问题

缺点： 在多语言环境中，必须为每个消费者去开发有这样一个客户端，升级成本和多语言支持成本会高些

方式三：在前面两种方式基础上作了一个折中，将LB功能以一个独立进程的方式部署在一台独立的主机上（既不是集中式LB，也不是在进程内客户端的LB），其余和方式二相似。

微服务API 服务网关（一）“原理”

公司内部通常会有不少微服务：购物车、库存、订单等，这些微服务是每一个团队各自独立维护的，但咱们不但愿外部用户访问的时候知道这些细节。这时候就能够经过网关来屏蔽这些细节，让客户看到的企业内部这些服务的时候像是一个服务。

屏蔽内部细节，暴露统一接口

为何在接入网关前有一层负载均衡？是想让网关是无状态的（无状态网关好处：能够部署不少，不会有单点，即便挂了一台其余网关还在，这对整个系统的稳定性和可用性很是重要）。

网关基本功能：

1. 反向路由，将外部的请求转换成内部具体服务的调用。与Nginx的反向代理功能相同
2. API 组合（这部分也可由聚合服务负责）
3. 协议转换，RESTful API 或 gRPC
4. 认证安全，恶意访问（爬虫，黑客等）
5. 限流熔断，突发流量（双11、促销等）以避免形成内部服务器瘫
6. 日志监控，对全部流量作访问的审计，对日志作分析

对请求的身份验证、受权、限流熔断、日志监控等的处理函数称为边缘函数。

微服务API服务网关（二）“开源网关Zuul”

Zuul过滤器：

1. Pre routing filters（前置路由过滤器）：如日志处理
2. Routing filters（路由过滤器）：目的找到目标服务并进行调
3. Post routing filters（后置路由过滤器）：响应回来通过后置路由过滤器会到客户端，在后置路由过滤器中能够作过后处理：日志、统计和审计等

(过滤器上传加载机制)

(Request Context 实如今各个阶段过滤器中分享相关信息。)

跟 Netflix 学习微服务路由发现体系

Netflix 两个核心组件：

1. 服务注册中心 – Eureka
2. 网关 – Zuul

内部微服务两层逻辑划分：

1.基础服务 – Netflix称：中间层服务2.聚合服务 – Netflix 称：Edge service（边界服务）

内部服务经过内部服务注册中心 Eureka 注册、发现。

1. 基础服务注册服务到服务中心
2. 聚合服务调用基础服务时，经过注册中心作服务发现，拉取路由表
3. 网关同步服务注册中心的路由表，当服务请求进来时网关根据路由表找到后台对应的聚合服务进行调用

服务注册中心还能够作服务治理，例如对服务调用的安全管控。

集中式配置中心的做用和原理

传统的作法在配置文件中作配置，而且每一个团队有各自的作法，这种作法的隐患：

1. 配置不标准，格式不统一
2. 上线后如遇重大事故，去响应并调整配置、去修改配置并从新发布，时间周期会比较长
3. 配置文件的修改没法审计、追溯

哪些须要集中配置：

• 连接字符串 - 数据库连接字符串、缓存连接字符串、消息队列链接字符串动态调整参数 - 超时时间、限流阈值
• 业务开关 – 地域性功能、促销时开放的功能

配置中心能够简单的认为是一个服务器，开发、运营人员能够经过界面对配置中心进行配置，咱们的服务连到配置中心后能够实时更新配置服务器中修改的配置。

更新的方式主要有两种：

1. 服务主动拉取配置 – Pull（弊端：有延迟）
2. 服务时刻连在Config Serve上，Config Server 有变动时会Push到每一个服务上（弊端：网络等缘由没能Push到某个服务上）

携程开源的配置中心 – Apollo

Apollo 配置中心（左侧）是一个服务器，研发或运营人员能够在服务端进行配置的修改，Apollo配置中心带有客户端（支持Java、.Net），客户端有一个缓存机制 – 配置更新后会拉取到客户端的内存缓存中，为了防止内存缓存的丢失客户端还会按期将内存缓存同步到本地文件缓存中，这样的设计可使得若是配置中心挂掉或应用程序重启后还能经过读取本地文件缓存。

服务的更新结合了配置推送 + 定时拉取，以保证高可用

微服务通信方式 RPC vs. REST

1. 耦合性：RPC - 服务端和客户端必须以特定的消息格式进行通信
2. 消息协议：RPC – 二进制：thrift、protobuf等，性能比较高；REST – 文本XML、JSON。payload会比二进制大
3. 通信协议：RPC – TCP协议；REST – HTPP/HTTP2
4. 性能：RPC – 高，REST – 基于文本消息协议和HTTP，差于RPC
5. 接口契约IDL：RPC – thrift、protobuf IDL；REST – Swagger
6. 客户端：RPC – 强类型客户端，通常自动生成、多语言支持；REST – 通常HTTP客户端可访问，可自动生成强类型客户端、多语言
7. 案例：RPC - Dubbo（阿里巴巴）、Motan（新浪微博）、Tars（腾讯）等；REST – SpringMVC/Boot、Jax-rs等
8. 开发者友好：RPC - 客户端比较方便，但二进制消息不可读；REST – 文本协议消息可读
9. 对外开放：RPC – 对外通常须要转换REST；REST – 直接对外开放

微服务架构须要考虑哪些治理环节

1. 服务注册发现
2. 负载均衡、路由（灰度发布、蓝绿部署 – 软路由能力）
3. 日志监控 – 问题排查
4. Metrics – 对服务的调用量、延迟等监控
5. 调用链埋点 – 微服务有错综复杂的依赖关系，若是没有好的调用链监控开发人员很容易迷失在这些服务中，出问题很难定位
6. 限流熔断
7. 安全 & 访问控制：黑名单、限制
8. REST/RPC
9. 序列化XML/JSON/二进制
10. 代码生成 – 大规模开发比较推崇一种契约驱动的开发方法，开发人员先定义契约而后用代码生成的方式自动生成客户端和服务器端，这个在大规模开发中生成的代码比较规整
11. 统一异常处理 – 异常标准化
12. 文档 – 方便开发人员接入
13. 配置集成
14. 后台服务集成 – DB、MQ、Cache

微服务治理就将这些环节沉淀下来变成框架或平台的一部分；开发人员专一于业务逻辑的实现，在实现业务逻辑的过程当中不须要考虑这个外围的治理能力。

这些治理环节沉在框架里，由框架团队或平台团队来集中管控。

完善的监控体系能实时了解微服务的健康状况对整个系统的可靠性和稳定性是很是重要的。

主要分为5 个层次发监控：

1. 基础设施监控（由运维团队负责，网络和交换机）- 网络流量、丢包、错包和链接数等
2. 系统层监控（物理机、虚拟机、OS） - CPU、内存、磁盘等
3. 应用层监控 – URL访问性能（技术、延迟）、服务、数据库SQL、Cache可用性（性能、命中率）、响应时间、QPS等
4. 应用层监控 – 登陆注册、下单、支付等
5. 端用户体验监控 – 性能、返回码、城市地区、运行商、操做系统等

5 个关键监控面：

• 日志监控
• Metrics监控
• 健康检查
• 调用链监控
• 告警系统

主流监控架构：

在主机或服务进程内安装Agent，Agent负责收集机器和应用中的日志和Metrics发送到咱们的监控系统。

当服务比较大、收集的日志和Metrics量比较大时会加入队列（Kafka）。标准的日志监控栈 – ELK（Elasticsearch、Logstash、Kibana）；Metrics会采用时间序列数据库（InfluxDB、Grafana呈现展现）

经过健康检查机制来按期对应用的健康进行自动化的检查，开源的工具备Nagios。

微服务的调用链监控该如何选择

原理： 当请求进入Web容器时会生成一个Span（图中Root Span），当继续调用Service 时又会生成一个Span（Child Span），请求进来进入Service会生成一个Span，Service调用DB或其余Service时会产生Span；Web应用在调用Cache时会产生Span。

Span是调用链造成的关键，在Span会有一些信息：Trace Id、Span Id等。Root Span比较特殊会生成Span Id和Trace Id，其余的Span会生成本身的Span Id同时为了维护调用链之间的父子关系Child Span会跟踪记录Parent Id。

在跨进程中为了使调用链持续连接，会将Trace Id和Parent Id一块儿带过来。

主流开源的调用链工具对比：

微服务的容错限流是如何工做的

Netflix Hystrix

熔断： 这一律念来源于电子工程中的断路器（Circuit Breaker）。在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统总体的可用性，能够暂时切断对下游服务的调用。这种牺牲局部，保全总体的措施就叫作熔断。

若是不采起熔断措施，咱们的系统会怎样呢？例子 当前系统中有A，B，C三个服务，服务A是上游，服务B是中游，服务C是下游。它们的调用链以下：

一旦下游服务 C 因某些缘由变得不可用，积压了大量请求，服务B的请求线程也随之阻塞。线程资源逐渐耗尽，使得服务B也变得不可用。紧接着，服务 A 也变为不可用，整个调用链路被拖垮。

像这种调用链路的连锁故障，叫作雪崩。

隔离： 是经过资源隔离减小风险的方式，源自货船为了进行防止漏水和火灾的扩散,会将货仓分隔为多个, 以下图所示。

软件系统的隔离推荐的方法是进行服务拆分，让每一个小业务独立运行，即使是其中一个业务宕掉，其余服务依然能够正常运行。

限流： 提早对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，再也不调用后续资源。

降级： 当服务器压力剧增的状况下，根据实际业务状况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运做或高效运做。

原理： 使用Hystrix 组件后，会将调用封装在Hystrix Command内，封装之后它就具备了熔断、限流、隔离和降级功能。请求方式能够是同步、异步或反应式的，请求过来后会作电路判断：若是电路打开即断路，会走降级流程调用降级函数。

若是电路闭合即没有熔断，而后进行线程/队列资源判断（若是资源不足，就会进入降级流程），若是前两关经过就运行调用。在调用时若是运行超时也会走降级流程。执行成功（Success）获取正确的相应结果返回调用端，失败走降级流程。

在整个调用过程当中，任何一个环节的相关信息（电路是否打开、线程是否占用、运行是否超时）都会以Metrics形式反馈给计算电路健康组件（Calculate Circuit Health）进而反馈给电路判断（指导下一次关闭/打开电路的判断依据）

Docker 容器部署技术 & 持续交付流水线

容器技术的优势：

1. 环境一致性
2. 镜像部署

流程： 开发人员提交代码到Git，经过Jenkins 完成构建、单元测试和打镜像并上传到镜像中心（Docker registry）。发布到测试环境经QA测试后升级到UAT环境，通过UAT测试后升级到生产环境（生产环境可能会经过灰度发布、蓝绿部署发布到生产环境）

蓝绿部署 + 灰度发布（经过软路由切换流量）保证服务的稳定性：

容器集群调度和基于容器的发布体系

---

「极客阅读 」汇聚了国内外最优质的技术博客、产品动态、公众号文章。开发者能够在极客阅读一站式的阅读到来自互联网技术大咖的文章。

「极客阅读 」官网：geeker-read.com