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

架构设计 / 2023-02-01 17:52:20
互联网微服務(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ě)崩”；
    返回顶部