微服务发展历程.md

微服务发展历程

单体服务，采用nginx网关

第1代微服务架构

从单体服务 到api网关，并api网关服务发现，请求后端服务。

业务自己实现一套 服务注册与发现、负载均衡、熔断降级策略、认证和授权、端到端trace、日志与监控功能。

第2代微服务架构

服务之间直接调用，集成了服务发现的sdk组件，负载均衡，熔断，鉴权等。

或者通过框架实现这一套功能。然业务在这个框架上实现自己的功能。

调用方 需要自己做流量管控，注册或订阅后端服务。

缺点

• 侵入性强。想要集成SDK，或使用定制化的rpc框架（如服务注册，服务订阅，流量控制sdk，rpc收发框架）；
• 升级成本高。每次升级都需要业务应用修改SDK版本，重新进行功能回归测试，重新部署升级。

第3代微服务架构

第三代微服务架构：service-mesh云原生解决方案

采用每个service（服务）与轻量级代理 sidecar部署在一个POD节点。

1. 【outbound】service的通过这个轻量级代理请求后端服务；
   • 后置1个轻量级代理
2. 【inbound】请求方需要访问这个后端服务时，也会前置一个轻量级代理，通过这个轻量级代理访问后端服务；
   • 前置1个轻量级代理

这样做到好处：

1. 业务方不用集成rpc微服务的组件。
2. 基础公务服务：流量控制，鉴权，可靠的rpc消息传递，日志与监控，统计等均由service-mesh基础组件（agent、controller）负责完成。
   • 方便基础组件升级，基础组件升级时不需要业务升级，甚至可以让业务无感知；
   • 业务开发效率更高；
3. 利用docker(k8s)的原生功能（如服务发现），动态扩容等，如何到k8s，更好的为业务开发服务。

优点：

• 业务 与 agent(数据面)完全解耦；
  • 业务不需要集成sdk或定制化的rpc框架。agent里面实现了这些基础组件，只需要使用方通过控制面下发配置。

小结

service-mesh开发、升级演进

1. 技术选型，demo验证；并开发最基础功能
2. 小规模试用，并做好长稳测试；
3. 运行稳定后，逐步推广；

微服务生态

• 服务发现 服务订阅、服务发现

• 流量控制

  • 路由规则，负载均衡

• 安全防御

  • 防止攻击

• 日志与监控

• 告警系统

感悟

• 做基础架构，代码质量要求非常高； -- 一点小的失误，因为几乎所有服务依赖它，可能导致严重后果。

• 如果对微服务发展历程不是很清楚，可以更加直观形象的描述。如下：

  • 单体服务，加上nginx做接入api网关；
  • 加上服务订阅，服务发现sdk组件；让服务之间调用时可以动态的拉去服务ip列表，并选中其中的1个节点进行 服务请求；
  • 遇到sdk组件升级的问题，代价太高。另外就是基本上云docker, k8s；为了与业务解耦；并使用k8s原生的服务发现等，采用了每个进程挂载1个轻量级代理。通过k8s api-server下发配置。-- 然后形成了现在服务网格概念。

• 要结合公司先用的资源，最小代价开发出适合自己业务的微服务解决方案。所以在service-mesh解决方案，我们的控制面和数据面采用的自研解决方案。

service-mesh核心基础功能

1. service-mesh包括2大组件 controller和agent

2. 核心基础功能是agent轻量级代理

   • 可靠转发： 链接管理（与客户端的链接管理，与服务端的链接管理）；
     • 怎样防止链接泄露？
   • io读写：
     • 怎样做到性能最佳？
   • 平滑升级/链接迁移
     • 因为涉及到agent进程升级，怎样让业务端尽量无感知，损伤最小？
   • 收发队列的设计
     • 怎样做到链接之间相互不影响？
   • cpu优化？
   • 内存优化?
     • 设计数据结构时就要节约内存资源；
     • 处理流程中，将使用完的内存及时释放掉；

3. 各种工具的使用，perf分析cpu，内存消耗。并进行优化。

技术功底

• 开发效率

  • golang/nodejs开发效率高
  • c++开发音视频转发逻辑非常好

• 部署

  • 部署安全，后端尽量避免使用js；-- 部署在云机器，依赖多，并且js代码可能泄露。
  • js只是开发初期开发效率高，后期维护成本高，因为代码泄露，容易被攻击；

参考链接

• 微服务及其演进史