《微服务架构核心20讲》学习笔记

本文是极客时间《微服务架构核心20讲》课程的学习笔记。

这个视频作者架构师杨波的下面这篇文章也很不错，喜欢的也可一并学习下。

微服务架构技术栈选型手册 https://www.infoq.cn/article/micro-service-technology-stack

第1讲 什么是微服务架构

Martin flower在博文中给出的微服务的特点如下：

• 一组小的服务

• 独立的进程

• 轻量级部署

• 基于业务能力（用户服务、登录服务、商品服务）

• 独立部署（每个团队维护自己的服务，团队之间不需要协调）

• 无集中式管理

 

Netflix前架构师给出的微服务的定义：

Loosely coupled（松散耦合，服务之间非强依赖）

Service Oriented architecture（本质上还是SOA）

with bounded context（服务之间有边界，可独立演化）

 

第2讲 微服务的利弊

讲了微服务的利和弊

微服务的利

• 强模块化边界

• 可独立部署

• 技术多样性

微服务的弊

• 分布式复杂性（相对于单体应用，现在，细分成很多服务，开发人员无法理解整个系统是如何工作的。）

• 最终一致性

• 运维复杂性

• 测试复杂性（对于单体应用，直接测试整个系统功能就可以了；微服务后，各个系统分散在各个团队，需要多个团队联调做集成测试。）

（我自己的理解：

关于微服务的利与弊，其实就是把一个系统细分为多个服务后，系统可看做整体，每个微服务可看做部分。好处是容易把控每个微服务自己，各个团队负责自己的服务就好了，坏处就是对系统整体的把握上会出现一些不便，比如对系统整理的理解、对系统的测试等）

 

思考以下问题：

运维团队，面对微服务的时候，应该采用什么样的手段来应对运维复杂性？

 

第3讲 康威法则

康威法则：系统的架构等价于组织的架构。

（我自己的理解就是：

如果系统是单体应用，那么应该是一个团队负责。

如果系统微服务化以后，比如分为服务A，B，C，那么组织架构上，也应当划分为A，B，C三个团队，每个团队可独立迭代。

)

 

思考以下问题：

作为架构师， 为什么不仅仅要做技术架构，也要了解组织架构？

 

第4讲 企业应该什么时候引入微服务

单体优先原则：不宜过早引入微服务，因为系统初期对系统的未来发展无法预知，过早引入微服务风险较高。

（我自己的理解：

不要在系统初期直接上微服务架构，而是在系统演变过程中逐渐引入）

 

抛出的问题：

架构是设计出来的还是演进出来的？

 

第5讲 什么样的组织结构更适合微服务

传统的组织架构：

一个产品需要产品团队、用户体验团队、研发专家团队、测试专家团队、DBA专家团队、运维专家团队等。

微服务组织架构：

每个微服务团队end-end ownership，从开发到测试到运维等，统统自己负责，形成闭环

Archite--->Design--->Develo--->Reivew--->Test--->Deploy--->Run--->Support

 

思考以下问题：

Netflix前总架构师说了一句话，微服务架构本质上是组织架构的重组，你如何理解这句话？

 

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

大中台，小前台。 强化“技术中台+业务中台”，中台肥沃，在这上面的业务生态才会更繁荣。业务应用更小更灵活，迭代能力变强，按照市场变化不断演化新应用出来。

 

思考以下问题：

大中台，小前台战略。每个架构师怎样在每个公司内部实践。

 

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

基础服务：也叫核心领域服务、公共服务、中间层服务

聚合服务：也叫适配服务、边界服务

 

第8讲 微服务总体技术架构体系是怎样设计的？

 

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

第1种：传统基于LB的模式

使用硬件的F5负载均衡器、软件的Nginx负载均衡器。

不足：1）服务配置、域名配置等需要运维介入 2）有一个集中LB，可能单点 

第2种：进程LB模式

不足：在多语言的环境当中，必须为每一个消费者开发响应的客户端，升级成本、都语言支持成本比较高

第3种：主机独立LB模式

将LB已独立进程的方式部署在主机上，既不是集中式LB，也不是进程内LB。

当调用的时候，主机上的LB会负责负载均衡。

优点：1）没有集中式LB的单点问题 2）对于调用方来说，多语言可以灵活地接入，无需为每种语言开发相应客服端

缺点：运维成本会比较高，因为在每台主机上要部署LB进程

（这种其实就是在每台主机上部署了个agent）

 

思考以下问题：

Service Mesh服务网格核心的点也是服务发现，那它使用了上面哪一种服务发现机制

 

第10讲 微服务API服务网关(一)原理

微服务中为什么要引入网关这个组件？

内部有许多微服务，由各自平台来维护，外部访问的时候需屏蔽细节，像是一个统一的服务。

 

为什么网关前面引入一个负载均衡器？
在接入网关时有一个负载均衡器，其作用是让网关是无状态的，这样的话，网关就可以部署很多，避免网关单点。

网关的职责：反向路由（将外面请求转换为内部ms的调用）、安全认证、限流熔断、日志监控（流量访问的日志）

 

第11讲 微服务API服务网关（二）开源网关Zuul

思考以下问题：

假如要设计一个防爬虫的功能，应该放在Filter的哪个阶段？Pre routing or Routing or Post Routing？

 

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

上面图画错了，【外部nginx】应为【外部LB】，【内部nginx】应为【内部LB】

服务注册中心：Eureka开源组件

网关层：Zuul开源组件

 

思考以下问题：

市面上有很多开源的组件，根据你的经验，参考以上架构，怎么来设计微服务架构服务发现体系？

 

第13讲 集中式配置中心的作用和原理是什么？

微服务中为什么要引入配置中心？它的作用是什么?

 

配置中心的配置如何下发到服务上？

1）push的方式

优点：可以实时更新。当配置修改了，就推送。

缺点：由于网络问题，可能导致没有推送到。

2）pull的方式

优点：一定能拉到。即使网络出现了问题，下次也一定能拉到，保证获取到最新的配置

缺点：非实时

3）push和pull相结合的方式

 

Spring cloud config、百度的difconf、携程的Apollo

本地文件缓存的作用？高可用：即使Apollo配置中心挂了，服务重启时，配置不会丢失。

配置中心配置下发采用push和pull相结合的方式。

 

第14讲 微服务通讯方式 RPC vs REST

耦合性：

RPC是强耦合，采用定制的消息格式，服务端和客户端之间必须以特定的消息格式进行通讯。

 

第15讲 微服务框架需要考虑哪些治理环节

 

思考以下问题：

Dubbo是如何将这些功能融合在框架中的

 

第16讲 微服务监控系统分层和监控架构

 

第17讲 微服务的调用链监控该如何选型

 

第18讲 微服务的容错限流是如何工作的

熔断、隔离

限流、降级

 

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

环境一致性问题

镜像部署问题

 

第20讲 容器集群调度和基于容器的发布