微服务笔记
为什么微服务
单体架构 web架构 巨石应用，开发前阶段容易测试部署开发随着业务发展，体量变大，业务之间依赖程度变大 代码量变大 影响到开发的进度和质量 风险的保障
开发效率部署效率降低
扩容单体架构
对资源的浪费太大 收益太低，对应用的扩展整个系统的认知复杂度变大
微服务
化繁为简，将应用拆分为小的应用独立开发环境 独立部署 独立上线 独立扩缩容一个服务专注一个业务，代码量少易于测试 维护，易于迭代优化。
复杂度高 ，不同的微服务可以通过rpc 消息队列来进行通讯，可以使用不同的语言数据库实现当前的微服务
测试难度增大 一个服务依赖多个微服务 微服务的升级可能会牵一发动全身
API GetAway+BFF?在当前层进行身份认证与授权
去中心化： 技术方向 数据访问Open
依赖基础设施自动化 搭建微服务部署于测试 gitlab gitlab hooks k8s
微服务api兼容性 接口契约
微服务划分
通过业务职能或DDD进行业务划分
公司内部不同部门提供职能。
通过领域驱动DDD理念进行拆分
CQRS
命令端提供CRUD请求提供触发事件
查询端口？
微服务通信
微服务通信rpc，rpc实现方式有http方式 grpc 有基于TCP的rpc框架
Grpc
1，支持各种多种语言序列号支持protobuff json
2, 基于文件的服务通过proto3 生成不同的语言protobuffer接口文件由于swaggerui 文档与代码不同步
3，主动健康检查，服务不稳定临时从负载中一处，待恢复后重新加入请求
服务发现
1，客户端发现
2，服务端发现