一、微服务概览

1. 微服务简介

微服务的Overview，设计思路，核心重点，简单减少了微服务的优缺点，以及结合B站业务如何来完成的落地，以及对现有新老系统；

2. 巨石架构和微服务

从现有系统迁移，新老接口，以及新老系统完成整合的方案和细节；

3. 微服务带来的困难

服务碎片化带来的rpc性能开销，可用性下降，以及治理的复杂度，给运维基础设施和测试带来的挑战非常之大

二、微服务网关

1. 网关架构

API 网关要做很多工作，它作为一个系统的后端总入口，承载着所有服务的组合路由转换等工作，除此之外，我们一般也会把安全，限流，缓存，日志，监控，重试，熔断等放到 API 网关来做，那么可以试想在高并发的情况下，这里可能会出现一个性能瓶颈。

2. 网关的工作模式

网关一般属于数据组装聚合，协议分解的层，需要考虑并发的性能，使用类似Future编程来解决扇出rpc问题，用户流量的接入层，一般不对内再提供接口服务。
3. 网关的实现

各种语言都与网关的框架，主要是HTTP服务，需要有一定的Middleware的扩展能力

三、微服务服务

1. rpc框架

gRPC vs Thrift vs HTTP RESTful，在协议设计、可用性、以及扩展等方面，以及rpc框架背后的功能集成和扩展能力；

2. api协议设计

api协议是server-client的浇水，api协议设立覆盖了大量的工程实践，哪些错误码返回，哪些数据返回，都有讲究，好的协议是面向业务场景的，收敛的。

3. 服务发现和注册

SLB集中式的负载均衡，还是客户端发现实现的负载均衡，在AP、CP系统上如何选择，服务发现的原理和细节，目前Eureka存在的一些问题；

4. 负载均衡和调度

在跨机房、灰度发布时候如何基于服务注册的元数据信息完成的服务流量调度，以及如何均衡的选择上，比如是随机、rr、wrr等，应该是如何来如何选择，以及wrr对我们线上容器有什么影响；

5. 多集群

服务需要考虑集群级别的隔离和容灾，提供更多的冗余和弹性能力，比如我们L0核心的业务，如果只有一套是存在风险的。

四、微服务中间件

1. 分布式队列

消息系统如何给系统解耦，以及如何处理分布式一致性，比如我们经常遇到的cache一致性问题；

2. 系统/APM监控

业务层监控：关注业务指标，比如注册成功率、投稿成功率；

应用层监控：关注App/Web业务“端”监控，链路层监控，日志Logview，异常监控；

系统层监控：包含所有网络、IDC、CDN、中间件、数据库等底层组件监控；

3. 服务注册中心

Netflix Eureka是一个高度AP的系统，即使只有一个实例存活，仍可以提供服务，并在集群或网络恢复后能在一定时间后（30秒）一致。基本原理可以理解为实例之间相互广播以达成最终一致，中间可能发生的数据丢失由客户端定期注册解决。这个设计的合理性在于上游一般并不需要所有的下游存活，一段时间内的不一致并不会导致巨大的问题，反倒是作为基础服务的可用性，易维护性会更加重要。

4. 配置中心

统一唯一的配置管理，配置文件的治理是对微服务至关重要的，变更管理是根本影响服务可用的关键因素。

五、微服务可用性设计

1. 微服务隔离原则

不同类型的请求使用线程池来资源隔离，每种类型的请求互不影响，如果一种类型的请求线程资源耗尽，则对后续的该类型请求直接返回，不再调用后续资源；

2. 微服务超时控制

针对服务超时，可以通过超时控制保证接口的返回，可以通过设置超时时间为1s，尽快返回结果，因为大多数情况下，接口超时一方面影响用户体验，一方面可能是由于后端依赖出现了问题，如负载过高，机器故障等。某个互联网公司曾经说，当系统故障时，fail fast；

3. 微服务限流实现

微服务开发中有时需要对API做限流保护，防止网络攻击，比如做一个短信验证码API，限制客户端的请求速率能在一定程度上抵御短信轰炸攻击，降低损失；

4. 微服务降级

有些情况下，即使服务出错，对用户而言，也希望是透明的，无感的，设置一些fallback，做一些服务降级，保证用户的体验，即使这个服务实际上是挂掉的，返回内容是空的或者是旧的，在此故障期间，程序员能赶紧修复，对用户几乎没有造成不良体验；

5. 微服务容错方案

直面意思就是可以容下错误，不让错误再次扩张，让这个错误产生的影响在一个固定的边界之内，微服务之间通过网络进行通信，进行互相调用，造成了微服务之间存在依赖关系。我们知道由于网络原因或者自身的原因，服务并不能保证服务的100%可用，如果单个服务出现问题，调用这个服务就会出现网络延迟甚至调用失败，而调用失败又会造成用户刷新页面并再次尝试调用，再加上其它服务调用，从而增加了服务器的负载，导致服务瘫痪，最终甚至会导致整个服务“雪崩”；