《极客时间教程 - 微服务架构核心 20 讲》笔记
《极客时间教程 - 微服务架构核心 20 讲》笔记
什么是微服务架构
微服务是一种架构模式。
微服务的六个特点：
- 一组小的服务
- 独立的进程
- 独立部署
- 轻量级通信
- 基于业务能力
- 无集中式管理——这里指的是可以用不同的技术栈，不同的存储
微服务定义：基于有界上下文的、松散耦合的、面向服务的架构。
架构师如何权衡微服务的利弊
架构之道在于权衡利弊。
微服务架构的优点
- 强模块化边界
- 可独立部署
- 技术多样性
微服务架构的缺点
- 分布式系统复杂性
- 最终一致性
- 运维复杂性
- 测试复杂性
分布式系统带来的一个挑战就是取终一致性。
康威法则和微服务给架构师怎样的启示
康威法则：设计系统的架构受制于产生这些设计的组织的沟通结构。
康威的原文中提出的各定律
- 第一定律 组织沟通方式会通过系统设计表达出来
- 第二定律 时间再多一件事情也不可能做的完美，但总有时间做完一件事情
- 第三定律 线型系统和线型组织架构间有潜在的异质同态特性
- 第四定律 大的系统组织总是比小系统更倾向于分解
其中心思想实际就是分而治之。
企业应该在什么时候开始考虑引入微服务
微服务的适用性:
微服务重在服务治理，其对于平台基础设施有较高要求，所以企业刚开始应用微服务并不一定能提高生产力。简单来说：单体服务适用于小团队；微服务适用于大团队。
何时选择微服务，在于度的把控。当研发团队人员增长到一定程度，沟通成本不断增长时，就可以考虑微服务架构了。一个经验数据是，当团队达到 100 人规模时，就可以考虑使用微服务架构了。
罗马不是一天建成的：架构是一个演进的过程，不应该一开始就将系统设计的过于复杂。
什么样组织架构更适合微服务
左边是比较传统的组织架构。产品从左到右流程走，可能出现的问题，反馈比较慢，对业务支持比较慢。沟通成本比较大。
右边是比较合适微服务的组织架构， 每一个团队（基于微服务的跨职能的团队），有开发，有产品，有测试，团队都支持自己的微服务。交付的产口是平台，对外提供 API 接口支持多样的业务。
DevOps 理念：谁开发的，谁构建，谁支持。
如何理解阿里巴巴提出的微服务
中台战略和微服务的关系
业务中台和技术中台统称为大中台，支撑业务前台。正所谓，万丈高楼平地起，中台基础越扎实，前台发展就越快。
PaaS 和 核心业务层是和微服务相关的。这一些基本都可以用微服务来实现。
IaaS：Infrastructure-as-a-Service（基础设施即服务）
PaaS：Platform-as-a-Service（平台即服务）
如何给出一个清晰简洁的服务分层方式
大致的服务分层图：
SOA（Service-Oriented Architecture）或微服务大致可分为
- 基础服务：也被称为：核心领域服务、中间层服务、公共服务
- 聚合服务：对基础服务的聚合，以满足业务需求，提供给外部调用。
微服务总体技术架构体系是怎么设计的
- 接入层：接入外部流量，内部做负载均衡
- 网关层：反向路由，限流，安全，跨横切面的功能。
- 业务服务层：可分为：聚合服务，基础服务
- 支撑服务：各种公共性的后台服务
- 平台服务：可以是一些管理系统
- 基础设施：由运维团队运维
其中，与微服务相关的主要有：网关层、业务服务层、支撑服务、平台服务
微服务最经典的三种服务发现机制
消费者（客户端）如何发现生产者（服务端），有三种模式：
（1）通过 DNS 访问 LB（负载均衡），LB 分发
（2）消费者内置 LB， 生产者将自身信息注册到注册中心上，并通过发送定时心跳来确认自身服务可用。消费者定期从注册中心拉取生产者信息
（3）结全前面两种方式， 在 Consumer 的主机上也布置一个 LB。 LB 会定期同步注册中心的信息。 运维成本比较高一点。
微服务 API 服务网关（一）原理
网关用于屏蔽服务内部的逻辑，希望外部访问看到是统一的接口。
网关主要的功能：
- 反向代理：将外部的请求换成内部调用。
- 安全认证：防刷、防爬虫。
- 限流熔断：处理可能会突发流量。
- 日志监控：进行访问访问审计，监控流量。
一般不要把过多的业务逻辑写在网关当中。
服务 API 服务网关（二）开源网关 Zuul
Servlet 和 Filter Runner 过滤器：前置路由过滤器， 路由过滤器，后置路由过滤器
过滤器开发，可以通过脚本开发。开发完后上传到过滤器目录中， 被扫描后加到 Filter Runner 中。
各个 Filter 共享数据通过 Request Context 来实现。
过滤链的流程：
跟 Netflix 学习微服务路由发现体系
netflix 有两个比较重要的支撑服务
- 服务注册中心 Eureka
- 网关 zuul
集中式配置中心的作用和原理是什么
为什么要引入配置中心呢？
配置文件中的属性不方便管理，无法动态更新，无法审计。配置中心可以解决这些问题。
什么可做配置呢？
- 业务开关
- 调用/响应超时
- 限流
- 连接字符串
- 动态参数
Svr 更新配置有两种方式：推和拉。
携程的 Apollo 配置中心:
github : https://github.com/ctripcorp/apollo
微服务通讯方式 RPC vs REST
RPC：远程过程调用
REST：Restful
微服务框架需要考虑哪些治理环节
一个公司的微服务多了，就要需要考虑服务治理：
软负载：蓝绿发布，灰度发布
指标（Metrics）：服务的调用量，耗时监控
调用链埋点：方便快速定位问题
契约生成代码： 定义结构体可自动生成 json 格式， vscode 有插件。
阿里巴巴微服务治理生态：Dubbo http://dubbo.apache.org/en-us/
微服务监控系统分层和监控架构
五个层次的监控：
- 基础层施监控
- 系统层监控
- 应用层监控
- url
- sevice
- mysql
- cache 可用率
- 性能
- qps
- 业务层监控
- 核心指标监控
- 登录注册
- 端用户体验监控
- 日志监控：Elasticsearch
- metrics 监控
- 健康检查
- 调用链监控
- 告警系统
比较典型的监控架构，大部分公司的流程
数据量比较大一般用 Kafka 作为缓冲队列。
Nagios 健康检测工具。
ELK：ELK 是 Elasticsearch、Logstash、Kibana 三大开源框架首字母大写简称。
微服务的调用链监控该如何选型
调用链的监控 谷歌 2010 年提出来的。
通过 Span 来跟踪， RootSpan ChildSpan 跨进程时 会有 Trace di + parant span id
三个主流调用链监控系统的比较：
微服务的容错限流是如何工作的
Netfiix Hystrix 具有熔断、隔离、限流、降级的功能 。
说明：
- 3 Cirult OPen 判断是否可以熔断， 是则执行 getFAllBack() 降级处理函数
- 5 run() 超时 也执行降级处理函数。
- 6 不成功也 执行处理函数 。
- Calculate Cirult Health 就是在正常执行成功后计算是否需要熔断。
Docker 容器部署技术 & 持续交付流水线
docker 容器治理就是解决：环境不一致的问题。把依赖的所有包都打在镜像中。
统一、标准化的交付流水线。
UAT 环境： User Acceptance Test （用户验收测试）
发布模式： 蓝绿布置，灰度发布（金丝雀发布）。
容器集群调度和基于容器的发布体系
资源调度框架 Mesos 架构
基于容器的云发布体系
