架构演化

各种技术、架构不断的推陈出新的目的就是解决以往无法解决或解决起来很复杂的问题。

单体应用

即一个程序、软件包包含所有功能的程序。

存在问题

• 部署效率低下
  • 你有体验过被 C++ 编译速度按在地上摩擦的恐惧吗？（好好想想 Java 的咖啡 icon 是这么来的）
• 团队协作成本高
  • 人越多、团队越大，影响越大
• 系统高可用差
  • 一个功能模块崩溃可能导致所有功能崩溃
• 线上发布慢
  • 服务器规模变大之后，部署会越来越慢

服务化

通俗来讲就是，将传统单体应用中的一些可分离的本地调用功能封装成一个独立的，以 RPC、HTTP 等协议来访问提供功能的程序（服务）。

微服务

特点

• 拆分粒度更细
  • 适可而止
  • 随业务发展、团队规模变迁调整
• 服务独立部署
• 服务独立维护
• 服务治理能力要求高

单体应用到微服务

1. 首先要明确指定是不是需要转到微服务？
   • 判断项目状态
     • 业务复杂度（奉劝各位有志当老板的客官，前期不用搞太复杂，不然容易浪费大量精力反而得不到应有的收益）
     • 用户量（并发等）
     • 稳定性要求
   • 判断团队规模
     • 整体、个体技术水平（相对来说还好，要求不算很高，但是需要有一到两个能搞事情的人）
     • 人员数量（人数多单体应用管理会变复杂，人数多少影响拆分粒度等）
2. 怎么转？
   • 打地基（微服务）
     • 服务定义
       • 接口协议
     • 服务发布、订阅
       • 注册中心（记录服务提供信息：地址、端口等）
     • 服务监控
       • 数据埋点、收集、处理、展示
     • 服务治理
       • 熔断等
     • 服务故障定位
       • 能在多个系统中传递的用于标记一次用户请求的方案
   • 拆单体
     • 纵向拆分（从业务维度拆分）
       • 按照业务关联程度拆分（关联密切的拆到一起为一个微服务）
     • 横向拆分（从公共且独立功能的维度拆分）
       • 按照是否有公共的被其它服务调用，且依赖资源独立，不与其它业务耦合

初窥微服务

服务调用依赖的基本组件

• 服务描述（框架）
  • 目的：服务名、调用要求、调用结果描述等
  • 方法：RESTFul API（HTTP）、XML（RPC）、IDL 文件（gRPC） 等
• 注册中心
  • 目的：提供服务供外部感知、使用
  • 方法：程序、文件等
    • 流程
      • 服务提供者注册服务到注册中心
      • 服务消费者向注册中心订阅服务
      • 注册中心反馈注册信息给消费者（服务发生变化时，通知消费者）
• 服务监控
  • 目的及方法：收集、处理、展示（预警等）用户调用数据
• 服务追踪
  • 目的：便于故障追踪、问题定位
  • 方法：使用标记关联每次调用，使调用链路始终可追溯
• 服务治理
  • 目的：保证服务在各种意外下仍然保持可用
  • 方法：单机故障处理、IDC 故障处理、依赖服务不可用处理、自动扩缩容等