目录
- 服务拆分与服务发现
- 微服务框架选择
- 服务间通信
- 服务编排
- 配置管理
- 服务端保护机制
- 监控
- API监控
- 服务调用链
- 服务负载
- 基础依赖监控
- 日志分析
Monolithic vs Microservice
| Monolithic | Microservice | |
|---|---|---|
| 开发测试 | Java类语言项目越大，运行调试需要越多的编译时间，本地调试有较多依赖，况且业务复杂后不易新人上手 | 只有部分功能的代码，运行更快速，根据业务划分，方便新人上手 |
| 部署 | 更新整个项目 | 更新一个微服务 |
| 生产调试 | 日志集中，调试方便 | 日志分散，服务依赖复杂；拓容简便 |
这两种架构视乎业务的复杂程度和代码量的大小，复杂程度低于一定程度，还是单一应用开发更快速，部署更加容易，因为服务拆分和线上的调试这些都是需要成本，反之，当业务不断增加，代码不断膨胀，服务拆分显得逐渐重要，公共功能能抽出来做成基础服务，各个业务所需的轮子也不需要重新造一遍，反而节省了开发成本，同时对于新人的加入，由于服务职责单一，让新人进来一个一个服务地熟悉，好过于一个大而全的项目。
微服务基础架构
处理流程
- 浏览器发起下单请求到负载均衡(LB)
- 负载均衡派发请求到API gateway
- API gateway查询服务发现，找到user服务和store服务，将用户信息和商品ID发送给store服务，
- store服务查询MySQL，找到商品信息，生成订单信息，将请求发送给payment服务
- payment服务根据用户指定的支付渠道，向第三方服务发起请求，存储订单信息，并返回订单状态
- store服务 -> API gateway -> LB
- LB返回数据到浏览器
微服务技术
