C. 高可扩展架构 — 微服务架构

SOA的区别

• 服务粒度
  • SOA：粗
  • 微服务：细
• 服务通信
  • SOA：重量级，ESB
  • 微服务：轻量级，HTTP、RPC
• 服务交付
  • SOA：慢
  • 微服务：快
• 应用场景
  • SOA：企业级
  • 微服务：互联网

微服务的坑

• 服务划分过细，服务间关系复杂
• 服务数量太多，团队效率急剧下降
• 调用链太长，性能下降
• 调用链太长，问题定位困难
• 没有自动化支撑，无法快速交付
• 没有微服务治理
  • 问题
    • 服务路由
    • 服务故障隔离
    • 服务注册和发现

思路

• 服务拆分：粒度
  • 业务开发初期，可以三个人维护一个服务，等系统成熟稳定了，可以一个人维护多个服务
• 拆分的思路
  • 纵向拆分
  • 横向拆分
• 问题
  • 服务如何定义
  • 服务如何发布和订阅
  • 服务如何监控
  • 服务如何治理
  • 故障如何定位

拆分方法

• 基于业务逻辑拆分：这是最常见的一种拆分方式，将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务。
• 基于可扩展拆分
  • 将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务
• 基于可靠性拆分
  • 避免非核心服务故障影响核心服务：比如说日志服务和订单服务
  • 核心服务高可用方案可以更简单：核心服务的功能逻辑更加简单，存储的数据可能更少，用到的组件也会更少，设计高可用方案大部分情况下要比不拆分简单很多。
  • 能够降低高可用成本：将核心服务拆分出来后，核心服务占用的机器、带宽等资源比不拆分要少很多。因此，只针对核心服务做高可用方案，机器、带宽等成本比不拆分要节省较多。
• 基于性能的拆分：基于性能拆分和基于可靠性拆分类似，将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务。常见的拆分方式和具体的性能瓶颈有关，可以拆分 Web 服务、数据库、缓存等。例如电商的抢购，性能压力最大的是入口的排队功能，可以将排队功能独立为一个服务。

基础设施

• 自动化测试：自动化测试涵盖的范围包括代码级的单元测试、单个系统级的集成测试、系统间的接口测试，理想情况是每类测试都自动化。如果因为团队规模和人力的原因无法全面覆盖，至少要做到接口测试自动化。
• 自动化部署：自动化部署系统包括版本管理、资源管理（例如，机器管理、虚拟机管理）、部署操作、回退操作等功能。
• 配置中心：配置中心包括配置版本管理（例如，同样的微服务，有 10 个节点是给移动用户服务的，有 20 个节点给联通用户服务的，配置项都一样，配置值不一样）、增删改查配置、节点管理、配置同步、配置推送等功能。
• 接口框架：微服务提倡轻量级的通信方式，一般采用 HTTP/REST 或者 RPC 方式统一接口协议。但在实践过程中，光统一接口协议还不够，还需要统一接口传递的数据格式。
• API 网关：API 网关是外部系统访问的接口，所有的外部系统接⼊系统都需要通过 API 网关，主要包括接入鉴权（是否允许接入）、权限控制（可以访问哪些功能）、传输加密、请求路由、流量控制等功能。
• 服务发现：
  • 自理式：自理式结构就是指每个微服务自己完成服务发现。
    • 优缺点：自理式服务发现实现比较简单，因为这部分的功能一般通过统一的程序库或者程序包提供给各个微服务调用，而不会每个微服务都自己来重复实现一遍；并且由于每个微服务都承担了服务发现的功能，访问压力分散到了各个微服务节点，性能和可用性上不存在明显的压力和风险。
  • 代理式：代理式结构就是指微服务之间有一个负载均衡系统（图中的 LOAD BALANCER 节点），由负载均衡系统来完成微服务之间的服务发现。
    • 优缺点：不管是自理式还是代理式，服务发现的核心功能就是服务注册表，注册表记录了所有的服务节点的配置和状态，每个微服务启动后都需要将自己的信息注册到服务注册表，然后由微服务或者 LOAD BALANCER 系统到服务注册表查询可用服务。
• 服务路由：服务路由和服务发现紧密相关，服务路由一般不会设计成一个独立运行的系统，通常情况下是和服务发现放在一起实现的。对于自理式服务发现，服务路由是微服务内部实现的；对于代理式服务发现，服务路由是由 LOAD BALANCER 系统实现的。无论放在哪里实现，服务路由核心的功能就是路由算法。常见的路由算法有：随机路由、轮询路由、最小压力路由、最小连接数路由等。
• 服务容错：常见的服务容错包括请求重试、流控和服务隔离。通常情况下，服务容错会集成在服务发现和服务路由系统中。
• 服务监控
  • 实时搜集信息并进行分析，避免故障后再来分析，减少了处理时间。
  • 服务监控可以在实时分析的基础上进行预警，在问题萌芽的阶段发觉并预警，降低了问题影响的范围和时间。
• 服务跟踪：目前无论是分布式跟踪还是微服务的服务跟踪，绝大部分请求跟踪的实现技术都基于 Google 的 Dapper 论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》。
• 服务安全：服务安全主要分为三部分：接入安全、数据安全、传输安全。通常情况下，服务安全可以集成到配置中心系统中进行实现，即配置中心配置微服务的接入安全策略和数据安全策略，微服务节点从配置中心获取这些配置信息，然后在处理具体的微服务调用请求时根据安全策略进行处理。由于这些策略是通用的，一般会把策略封装成通用的库提供给各个微服务调用。