微服务架构初探 | 青训营笔记

53 阅读4分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 10 天


本堂课主要内容是微服务架构,下面是我个人听课时的一些笔记。主要是微服务架构介绍微服务架构原理及特征两部分内容,后续内容见下一篇笔记。

个人笔记

微服务架构介绍

微服务架构的背景由来、架构概览、基本要素。

  • 系统架构演变历史

    • 单体架构:

      all in one process

      优势:性能最高,且系统冗余小

      劣势:debug困难,模块之间依赖强,开发流程复杂,分工不清晰

    • 垂直应用架构:

      按照业务线垂直划分

      优势:业务独立开发维护

      劣势:不同业务存在冗余、每个业务还是单体架构

    • 分布式架构:

      抽出业务无关的公共模块

      优势:业务无关的独立服务

      劣势:单个服务模块的bug会导致全站瘫痪,调用关系复杂,不同服务之间存在冗余

    • SOA架构:( Service Oriented Architecture)

      面向服务

      优势:服务注册机制

      劣势:整个系统设计是中心化的,需要从上至下设计,且重构困难

    • 微服务架构:

      彻底的服务化

      优势:开发效率高,业务自下而上进行独立设计,可以实现故障隔离

      劣势:治理和运维难度高,安全性容易受到挑战

  • 微服务架构核心要素:

    • 服务治理(本次课主要内容)

      包括服务注册、服务发现、复杂均衡、扩缩容、流量治理和稳定性治理等等

    • 可观测性

      包括日志采集、日志分析、监控打点、监控大盘、异常报警、链路追踪等等

    • 安全

      包括身份验证、认证授权、访问令牌、审计、传输加密、黑产攻击等等

微服务架构原理及特征

微服务架构的基本组件、工作原理、流量特征。

  • 基本概念

    服务(service):一组具有相同逻辑的运行实体(相同服务运行相同的代码)

    实例(instance):一个服务中,每个运行实体即为一个实例;常见的实例承载形式:进程、Virtual Machine虚拟机、k8s pod

    实例与进程的关系:实例与进程之间没有必然对应关系,一个实例可以对应一个或多个进程(反之不常见)

    集群(cluster):通常指服务内部的逻辑划分,包含多个实例

    service>cluster>instance

    有状态/无状态服务:服务的实例是否存储了可持久化的数据(如磁盘文件)

    服务间通信:对于单体服务,不同模块通信只是简单地函数调用;对于微服务,服务间通信意味着网络传输,需要使用HTTP、RPC、Thrift等协议进行通信

  • 服务注册及发现

    对于网络通信功能,需要知道远程的IP地址和端口号Port

    不能些固定的ip和端口号

    联想TCP/IP协议栈中的地址映射协议DNS,通过将域名映射为IP地址,来实现通信对端地址的发现,但是微服务中服务的发现不能采取这种方法,原因是:

    • 本地DNS会先查询缓存,但服务地址会动态变化,会增加服务发现的延时

    • DNS的方法无法解决复杂均衡的问题

    • DNS不支持对服务实例的探活检查

    • DNS只能用于查找IP地址,不能配置端口

    解决思路:新增一个统一的服务注册中心,用于存储服务名到服务实例的映射。

    那么服务实例的上线及下线过程分别是将对应实例的映射关系从服务注册中心新增和删除

    (上线新服务后会有health check的过程,确保新上线的实例可以处理请求)

    (先删除实例,再下线服务的映射)

  • 流量特征:

    从流量的视角说明微服务架构

    • 统一网关入口,所有请求都需要经过API Gateway,这个过程中可以进行身份认证
    • 内网通信一般使用RPC协议,客户端与网关之间的通信采用HTTP协议
    • 同一个客户端长连接发出的请求,理论上可以到达服务中的所有实例,内网的服务构成网状调用链路

参考

  • 字节内部课 —【微服务架构原理与治理实践】