公司业务从单体逐渐转移到了微服务,一些总结。另外也可以当做一道面试题,题目如文章标题^_^
单体服务:
1. 初期优势:业务模块耦合度高,IPC通信简单(方法、函数直接调用,本地进程直接调用或者通过mq来异步通信)、(统一)部署快,测试快(依赖度相对较低)
2. 长期发展:代码量变大,越来越多类似的轮子被造出来,一个需求改变可能涉及到多个地方同步修改(迁一发能动全身),业务逻辑冗余复杂,老员工成了吉祥物。
微服务
3. 小试牛刀:停止单体服务下的无限制扩张。按业务线(线索、订单、商品、用户)分开,再按业务线细分(比如按表)
4. 小有欢喜:应用小(模版一键生成,干活少),独立部署和扩展;逻辑单一,维护性好;。
5. 渐入坑境:随着微服务的规模变大一大堆问题呈线性增加:部署频率增加,链路调用增加,对服务高可用受到挑战,监控(服务发现)治理,测试周期变长,问题定位困难,各个端业务规范不一致,单一服务上下游影响甚至拖垮整条链路(雪崩),数据库事务难以控制,粒度划分难(甩锅开始)
6. 善假于物:配置中心、再抽离基础库组件化与定时更新、统一业务方接口/RPC协议/服务规范,配合服务注册与发现,监控体系,业务网关、流量网关、权限网关、日志系统,分布式链路追踪,调度中心,持续集成,持续部署,负载均衡、熔断、限流,降级机制,server mesh。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。