分布式服务-发展历程

• 单机LAMP(LNMP)：Linux + Apache + Mysql + Php
  • 服务器不堪重负
• 应用服务器 + 数据库服务器 + 文件服务器
  • 数据库不堪重负
• 应用服务器(本地缓存) + 数据库服务器 + 文件服务器 + 远程分布式缓存
  • Apache不行了
• 负载均衡 + 应用服务器
  • 数据库读写竞争
• 数据库开启主从模式(写主读从)
  • Apache又吃不消了
• CDN + 反向代理 + 负载均衡 + 应用服务器
  • 数据不论读写都跟不上了
• 数据统一访问模块 + 分布式文件系统 + 分布式数据库（如果不是单表过大，其实可以业务分库）
  • 分布式数据库也吃不消了
• NoSQL + 搜索引擎（可跨库查询）
  • Apache又吃不消了
• 业务拆分（这台机器干这个，那台机器干那个）
  • 发现有些公共服务可以剥离
• 分布式服务
  • 理论上应用规模不再有上限；不过，分布式不代表就是优秀，能单机搞定的，why分布式
  • MapReduce/BigTable/DFS三篇论文，打开了大数据领域分布式的先河，任当今湖仓百花齐放，数据编织跃跃欲试，总能看见它们的影子
• Service Mesh
  • 没有脱离分布式服务概念，只是传统分布式服务中，存在业务代码与中间件代码耦合的问题，所以需要给业务代码/进程减负，代表作有Istio大礼包；核心概念是在云原生体系下，将业务代码无关的逻辑剥离，作为Sidecar/Agent来运行，这些众多Sidecar形成网状，也是Service Mesh名称的由来
• Service Runtime
  • Service Mesh中，尽管已经将大量业务无关逻辑（路由，流控，鉴权等等）下沉到Sidecar，但业务代码中依旧保留了对中间件轻量级SDK的依赖，同时，中间件对于多语言的适配亦不堪重负；在此背景下，Service Runtime应运而生，它的理念是给中间件定义语言无关的API，业务代码依靠gRPC与中间件Server端完成通信，代表作有Dapr和Layotto