要理解这个理念其实就是理解“如何处理复杂性”。为了更直观地理解我们可以用一个“公司组织架构”的类比来解释1. “大单体”应用Monolith—— 全能型员工想象一家公司只有一个员工。这个员工负责策划、编程、运营、财务、客服等所有工作。优点沟通成本极低因为所有事情都在一个人脑子里。问题痛苦所在难以扩展当业务变大这个人忙不过来想招人帮忙但因为所有任务都粘在一起新人根本插不上手。牵一发而动全身如果他今天要改一个财务报表格式不小心把客服系统的代码搞乱了整个公司就瘫痪了。技术债务代码库变得极其臃肿没人敢改动老代码。2. “解耦”与“微服务/RPC”—— 职能化分部门现在我们将公司拆分成不同的部门财务部、运营部、技术部等。解耦Decoupling各个部门之间通过标准化的流程比如发邮件、发工单来协作而不是直接干预对方的内部作业。Web Service / RPC远程过程调用这就是部门之间的“沟通协议”。RPC就像是公司内部的“电话会议”技术部直接拨打财务部的接口获取数据。Web Service就像是通用的“办公系统”任何部门只要按照标准格式提交请求就能得到结果。为什么这样做可以解决系统复杂性独立部署与扩展Scalability如果“结算功能”突然访问量暴增你只需要给“结算系统”加服务器而不用给整个应用加服务器。这在“大单体”中是做不到的。技术故障隔离Fault Isolation就像部门之间有防火墙。如果“推荐系统”因为代码 Bug 挂了不会导致“支付系统”也跟着崩溃。系统整体的可用性大大提升。技术栈自由Heterogeneity负责算法的团队可以用 Python负责高并发的团队可以用 Go负责前端交互的团队可以用 Node.js。只要大家定义好接口API内部用什么语言实现完全不影响对方。团队效率Team Autonomy不同的团队可以并行开发不用等待彼此的代码合并。只要合约API 接口定下来各自按进度上线即可。总结什么是“解耦”的代价虽然解耦很美好但它也引入了新的复杂度这就是所谓的“没有银弹”网络可靠性原来在内存里的函数调用现在变成了网络调用网络可能会断、会慢你需要处理超时、重试。数据一致性原来在一个数据库里改一行就完成了现在跨成了多个服务保证数据完全同步变得很麻烦这就是分布式事务的问题。简而言之所谓的解耦本质上是“牺牲了简单的本地同步调用换取了系统长期的维护性、灵活性和扩展性”。这也就是为什么现在行业内都在提倡微服务、Service Mesh 等技术的原因。
