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