公司刚上线那会儿，所有功能都堆在一个大项目里，用户管理、订单处理、支付接口全挤在一起。每次改个密码逻辑，都得连带测试整个系统，发版像拆炸弹，谁都不敢轻易点发布按钮。
\n\n从单体到拆分
\n后来用户量上来了，系统一出问题，整个应用就挂。运维同事半夜被叫起来重启服务，开发也头疼——明明只是商品详情页卡了，结果购物车也打不开。大家开始意识到，不能再这么混着干了。
\n\n于是团队决定拆。把用户相关的拎出来做成独立服务，订单也单独跑，支付模块交给另一个小组维护。每个部分自己部署、自己迭代，互不干扰。这就算是迈进了微服务的第一步。
\n\n服务之间怎么说话
\n刚开始拆完还挺爽，但没过多久新问题来了：用户注册成功后要通知订单系统初始化数据，两个服务怎么通气？最简单的办法是直接发 HTTP 请求。
\n\nPOST /api/v1/user-created HTTP/1.1\\nHost: order-service.local\\nContent-Type: application/json\\n\\n{\\n "userId": "12345",\\n "timestamp": 1719876543\\n}可一旦网络抖一下，消息丢了怎么办？有人提议用消息队列，把事件扔进 Kafka，谁感兴趣谁去消费。这样即使订单服务暂时不可用，等它恢复后还能补处理，可靠性高多了。
\n\n配置和发现的烦恼
\n服务越拆越多，IP 地址满天飞。开发小李每次联调都要问：“最新的用户服务地址是多少？” 测试环境改了三次，他本地还连着旧地址，查了一下午以为是代码 bug。
\n\n后来上了注册中心，比如 Consul 或 Eureka，服务启动时自动上报地址，其他服务通过名字就能找到它。再加上配置中心统一管参数，再也不用手动改 application.yml 了。
\n\n链路变长后的麻烦
\n一个请求进来，先过网关，再查用户服务，接着调权限，最后访问资源。中间哪一环慢了，整个响应就卡住。客户抱怨“页面转圈十几秒”，可查日志发现只有两三个接口特别慢。
\n\n这时候分布式追踪派上了用场。给每个请求生成唯一 trace ID，在各个服务间传递，最后拼出完整调用链。一看图就知道瓶颈在哪，不用再靠猜。
\n\n现在的样子
\n如今新项目基本默认按微服务设计，但不再盲目拆。团队更清楚边界该怎么划——按业务领域来，比如“会员”“营销”“库存”各自独立。通信方式也不只一种，实时强依赖走 RPC，异步事件用消息驱动。
\n\n容器化和 K8s 成了标配，一个命令就能拉起整套环境。CI/CD 流水线自动构建、灰度发布，运维压力小了不少。虽然复杂度没消失，只是被工具接过去了。
\n\n回头看，微服务不是一开始就规划好的蓝图，而是一步步被现实推着走出来的路。哪里堵了就疏通哪里，哪个环节反复出事就单独拎出来治。技术演进从来都不是理想主义的故事，而是无数个线上事故换来的经验。”,"seo_title":"微服务架构演进过程解析：从单体到分布式的服务变迁","seo_description":"了解微服务架构如何在实际业务中逐步演进，从单体应用拆分到服务治理，看真实场景下的技术迭代路径。","keywords":"微服务,架构演进,服务拆分,分布式系统,服务治理,微服务发展历程"}