互联网微服務(wù)架构实战

互联网微服務(wù)架构实战
    马上咨询


    毛老师  bilibili(B站)架构师 技术研发专家

    近十年的服務(wù)端研发经验,负责主站技术部研发管理(lǐ)工作。擅長(cháng)高性能(néng)、高可(kě)用(yòng)的服務(wù)端研发,熟悉Go语言。

    课程简介

    以实际重构过程中遇到的问题為(wèi)出发点切入到微服務(wù)的落地,加深对微服務(wù)本质的理(lǐ)解和带来的优劣的思考,给我们实际工作中微服務(wù)的高可(kě)用(yòng)、高性能(néng)、一致性等服務(wù)指标的提升带来巨大帮助。

    目标收益

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

    培训对象

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

    课程大纲

    课程大纲
    一、微服務(wù)概览
    1. 微服務(wù)简介
      微服務(wù)的Overview,设计思路,核心重点,简单减少了微服務(wù)的优缺点,以及结合B站业務(wù)如何来完成的落地,以及对现有(yǒu)新(xīn)老系统;
    2. 巨石架构和微服務(wù)
      从现有(yǒu)系统迁移,新(xīn)老接口,以及新(xīn)老系统完成整合的方案和细节;
    3. 微服務(wù)带来的困难
      服務(wù)碎片化带来的rpc性能(néng)开销,可(kě)用(yòng)性下降,以及治理(lǐ)的复杂度,给运维基础设施和测试带来的挑战非常之大
    二、微服務(wù)网关
    1. 网关架构
      API 网关要做很(hěn)多(duō)工作,它作為(wèi)一个系统的后端总入口,承载着所有(yǒu)服務(wù)的组合路由转换等工作,除此之外,我们一般也会把安全,限流,缓存,日志(zhì),监控,重试,熔断等放到 API 网关来做,那么可(kě)以试想在高并发的情况下,这里可(kě)能(néng)会出现一个性能(néng)瓶颈。
    2. 网关的工作模式
      网关一般属于数据组装聚合,协议分(fēn)解的层,需要考虑并发的性能(néng),使用(yòng)类似Future编程来解决扇出rpc问题,用(yòng)户流量的接入层,一般不对内再提供接口服務(wù)。
    3. 关的实现
      各种语言都与网关的框架,主要是HTTP服務(wù),需要有(yǒu)一定的Middleware的扩展能(néng)力
    三、微服務(wù)服務(wù)
    1. rpc框架
      gRPC vs Thrift vs HTTP RESTful,在协议设计、可(kě)用(yòng)性、以及扩展等方面,以及rpc框架背后的功能(néng)集成和扩展能(néng)力;
    2. api协议设计
      api协议是server-client的浇水,api协议设立覆盖了大量的工程实践,哪些错误码返回,哪些数据返回,都有(yǒu)讲究,好的协议是面向业務(wù)场景的,收敛的。
    3. 服務(wù)发现和注册
      SLB集中式的负载均衡,还是客户端发现实现的负载均衡,在AP、CP系统上如何选择,服務(wù)发现的原理(lǐ)和细节,目前Eureka存在的一些问题;
    4. 负载均衡和调度
      在跨机房、灰度发布时候如何基于服務(wù)注册的元数据信息完成的服務(wù)流量调度,以及如何均衡的选择上,比如是随机、rr、wrr等,应该是如何来如何选择,以及wrr对我们線(xiàn)上容器有(yǒu)什么影响;
    5. 多(duō)集群
      服務(wù)需要考虑集群级别的隔离和容灾,提供更多(duō)的冗余和弹性能(néng)力,比如我们L0核心的业務(wù),如果只有(yǒu)一套是存在风险的。
    四、微服務(wù)中间件
    1. 分(fēn)布式队列
      消息系统如何给系统解耦,以及如何处理(lǐ)分(fēn)布式一致性,比如我们经常遇到的cache一致性问题;
    2. 系统/APM监控
      业務(wù)层监控:关注业務(wù)指标,比如注册成功率、投稿成功率;
      应用(yòng)层监控:关注App/Web业務(wù)“端”监控,链路层监控,日志(zhì)Logview,异常监控;
      系统层监控:包含所有(yǒu)网络、IDC、CDN、中间件、数据库等底层组件监控;
    3. 服務(wù)注册中心
      Netflix Eureka是一个高度AP的系统,即使只有(yǒu)一个实例存活,仍可(kě)以提供服務(wù),并在集群或网络恢复后能(néng)在一定时间后(30秒(miǎo))一致。基本原理(lǐ)可(kě)以理(lǐ)解為(wèi)实例之间相互广播以达成最终一致,中间可(kě)能(néng)发生的数据丢失由客户端定期注册解决。这个设计的合理(lǐ)性在于上游一般并不需要所有(yǒu)的下游存活,一段时间内的不一致并不会导致巨大的问题,反倒是作為(wèi)基础服務(wù)的可(kě)用(yòng)性,易维护性会更加重要。
    4. 配置中心
      统一唯一的配置管理(lǐ),配置文(wén)件的治理(lǐ)是对微服務(wù)至关重要的,变更管理(lǐ)是根本影响服務(wù)可(kě)用(yòng)的关键因素。
    五、微服務(wù)可(kě)用(yòng)性设计
    1. 微服務(wù)隔离原则
      不同类型的请求使用(yòng)線(xiàn)程池来资源隔离,每种类型的请求互不影响,如果一种类型的请求線(xiàn)程资源耗尽,则对后续的该类型请求直接返回,不再调用(yòng)后续资源;
    2. 微服務(wù)超时控制
      针对服務(wù)超时,可(kě)以通过超时控制保证接口的返回,可(kě)以通过设置超时时间為(wèi)1s,尽快返回结果,因為(wèi)大多(duō)数情况下,接口超时一方面影响用(yòng)户體(tǐ)验,一方面可(kě)能(néng)是由于后端依赖出现了问题,如负载过高,机器故障等。某个互联网公司曾经说,当系统故障时,fail fast;
    3. 微服務(wù)限流实现
      微服務(wù)开发中有(yǒu)时需要对API做限流保护,防止网络攻击,比如做一个短信验证码API,限制客户端的请求速率能(néng)在一定程度上抵御短信轰炸攻击,降低损失;
    4. 微服務(wù)降级
      有(yǒu)些情况下,即使服務(wù)出错,对用(yòng)户而言,也希望是透明的,无感的,设置一些fallback,做一些服務(wù)降级,保证用(yòng)户的體(tǐ)验,即使这个服務(wù)实际上是挂掉的,返回内容是空的或者是旧的,在此故障期间,程序员能(néng)赶紧修复,对用(yòng)户几乎没有(yǒu)造成不良體(tǐ)验;
    5. 微服務(wù)容错方案
      直面意思就是可(kě)以容下错误,不让错误再次扩张,让这个错误产生的影响在一个固定的边界之内,微服務(wù)之间通过网络进行通信,进行互相调用(yòng),造成了微服務(wù)之间存在依赖关系。我们知道由于网络原因或者自身的原因,服務(wù)并不能(néng)保证服務(wù)的100%可(kě)用(yòng),如果单个服務(wù)出现问题,调用(yòng)这个服務(wù)就会出现网络延迟甚至调用(yòng)失败,而调用(yòng)失败又(yòu)会造成用(yòng)户刷新(xīn)页面并再次尝试调用(yòng),再加上其它服務(wù)调用(yòng),从而增加了服務(wù)器的负载,导致服務(wù)瘫痪,最终甚至会导致整个服務(wù)“雪(xuě)崩”;