课程费用

5800.00 /人

课程时长

2

课程排期

 
2019.12.21 -2019.12.22
广东 深圳 罗湖区,南湖路3018号 深圳皇冠假日套房酒店

2020.02.29 -2020.03.01
北京

成为教练

课程简介

以实际重构过程中遇到的问题为出发点切入到微服务的落地,加深对微服务本质的理解和带来的优劣的思考,给我们实际工作中微服务的高可用、高性能、一致性等服务指标的提升带来巨大帮助。

目标收益

加强研发工程师对微服务化开发模式的理解,以应对复杂业务密集的迭代带来质量、效率上的问题,简化我们应对复杂架构带来的系统复杂性问题。

培训对象

面向业务开发、架构师、运维、测试等关注服务端微服务化落地过程中涉及的工程师。

课程大纲

一、微服务概览 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%可用,如果单个服务出现问题,调用这个服务就会出现网络延迟甚至调用失败,而调用失败又会造成用户刷新页面并再次尝试调用,再加上其它服务调用,从而增加了服务器的负载,导致服务瘫痪,最终甚至会导致整个服务“雪崩”;
一、微服务概览
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%可用,如果单个服务出现问题,调用这个服务就会出现网络延迟甚至调用失败,而调用失败又会造成用户刷新页面并再次尝试调用,再加上其它服务调用,从而增加了服务器的负载,导致服务瘫痪,最终甚至会导致整个服务“雪崩”;

课程费用

5800.00 /人

课程时长

2

课程排期 (更新日期:2019.11.22)

scheduling->endTime - $model->scheduling->startTime) / 86400 ) ?>
2019.12.21 -2019.12.22
广东 深圳 罗湖区,南湖路3018号 深圳皇冠假日套房酒店

scheduling->endTime - $model->scheduling->startTime) / 86400 ) ?>
2020.02.29 -2020.03.01
北京

预约体验票 我要分享

近期公开课推荐

近期公开课推荐

提交需求