一、架构的演进
- 原始分布式。 通过多台计算机的协作，突破单机的性能瓶颈
- 单体
- SOA。 SOA架构包含多个服务， 服务之间可以通过服务总线进行通信， 最终提供一系列功能
- 微服务
- 无服务
二、不同架构的对比
| 对比项 | 微服务 | 微服务2.0(SM) | 无服务 | | —- | :—-: | :—-: | :—-: | | 概念 | 微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维 | 微服务基础上引入边车代理，进行流量劫持，负责服务发现、负载均衡、监控度量、日志追踪等 | 无服务器架构，开发者无需管理服务器，只需关注业务代码 | | 优点 | 模块间低耦合、敏捷开发， 支持不同技术栈 | 降低业务服务端复杂性； 对应用透明； 语言无关 | 无需考虑部署、运维等，降低闲置的机器资源成本等 | | 挑战 | 服务间调用、测试、运维部署复杂度提升 | 相当于增加一层Proxy, 通信性能会降低； 服务的稳定性强依赖边车 | 有冷启动时间；必须无状态； 和云厂商强绑 | | 适用场景 | 多技术栈；服务规模化 | 同微服务 | 离线大规模计算； 基于事件的数据处理（如视频处理的通用计算任务\loT后端服务） | | 框架实现 | web类框架：gin/beego等， rpc框架：gRpc, go-micro，自研（http和rpc均支持）| 同微服务 | 参考不同的云厂商提供的serverless应用（aws的lambda） | | 架构 | 参照后文各类的架构图 | 参照后文各类的架构图 | 参照后文各类的架构图 |
三、微服务
3.1 架构图
3.2 两大核心问题
- 服务发现
- 负载均衡 一般是加一层Proxy来负责，根据所处的位置， 可分为集中式代理、嵌入式代理、主机独立进程共用代理（进一步演变成ServiceMesh）
四、微服务2.0–ServiceMesh
4.1 架构图
开源实现：Istio, 边车用envoy实现。 目前看没有足够稳定的可用于生产环境的版本； 学习、配置成本大
4.2 通信交互模式
服务网格: 服务之间通过代理 发现和调用目标服务
k8s部署上可以在一个Pod里部署微服务实例和对应的边车代理
五、Serverless
5.1 架构图
5.2 两块内容
- FaaS：代码改造和部署工具都取决接入的云厂商
- BaaS(DB，日志，消息队列等)
六、结论
- ServiceMesh倾向于自研， 可用版本开发成本较小。 云厂商收费、且故障及时响应处理不能保证， 所以建议只用云厂商的基础设施
- Serverless根据个别场景，接入云厂商提供的服务
七、参考文档
- https://developer.aliyun.com/article/766206
- https://blog.csdn.net/baichoufei90/article/details/107293203
- http://icyfenix.cn/introduction/about-the-fenix-project.html
