微服务和云应用那些效率上的事儿，说说不完的坑和妙招

（来源：某电商平台资深架构师的技术分享沙龙记录）

这事儿得从我们公司决定把所有老系统都拆成微服务说起，当时老板觉得，你看人家大厂，动不动就成百上千个服务，弹性伸缩，多牛啊，我们一帮人也觉得，单体应用像个大泥球，改一处怕影响全身，发布一次全公司紧张,是得拆。

刚开始拆，那叫一个爽，每个小组负责一两个小服务，用自己最熟悉的技术栈，想用啥用啥，前端用Node.js，订单用Java，用户中心用Go，感觉开发效率飞起，但坑,也就从这儿开始一个个冒出来了。

第一个大坑就是“网络太脆弱”。（来源：团队一次严重的P0级故障复盘报告）以前单体应用，方法调用都在一台机器内存里完成，快得很，现在好了，用户下一个单，订单服务得通过网络去调用用户服务验身份，调用库存服务锁库存，调用优惠券服务算折扣，有一次，就因为优惠券服务所在的那台物理机网卡有点小问题，响应慢了两秒，导致订单服务的所有线程全被卡住等待，进而雪崩，整个下单链路全挂，那时候才明白，微服务是把双刃剑，一个点塌方，能引起整条高速公路瘫痪，后来我们学乖了，用了不少“妙招”，比如给每个调用设置超时时间，不能无限等；还有“熔断”机制，就像家里的电闸，发现某个服务老是超时，就自动“跳闸”，暂时不调用它了，给它时间恢复，免得被它拖死，再就是“降级”，比如优惠券服务挂了，咱们就先把订单正常生成，告诉用户优惠券暂时用不了，但东西可以先买,总比完全不能下单强。

第二个说不完的坑是“数据不一致”。（来源：财务对账时发现的长期数据差异问题）以前数据库在一起，一个事务搞定所有数据更新，ACID保证得妥妥的，现在用户余额扣了，订单生成了，但可能因为网络抖动，通知积分服务增加积分的消息没发出去，用户就少得了积分，为这事儿，没少被用户投诉，后来我们引入了“最终一致性”的概念，说白了就是承认我们没法像以前那样保证瞬间一致，但保证最终数据会是对的，妙招就是用了消息队列，比如RabbitMQ，扣钱成功的同时，发一条消息到队列里，积分服务慢慢从队列里取消息去给用户加积分，就算积分服务当时挂了，等它重启后还能继续处理消息，这样最终积分还是会加上，这对账系统就得做得更复杂了,天天得核对各种数据。

第三个头疼的问题是“测试和排查问题太费劲”。（来源：新入职开发工程师的吐槽）以前一个应用，拉下来代码，本地一跑，啥功能都能测，现在好了，服务几十个，你想本地测试一个“下单”功能，得先把用户服务、库存服务、优惠券服务……全在本地启动起来，光配环境就得一天，更可怕的是线上出了问题，日志散落在几十个服务里，你得像侦探一样，拿着一个订单号，去每个服务的日志里翻，拼凑出完整的线索链才知道到底哪一步出了错，这方面的妙招是引入了“分布式链路追踪”工具，比如SkyWalking，它能给每个请求分配一个唯一的ID，这个请求经过的所有服务都会带着这个ID，并把日志和性能数据报告给一个统一的平台，这样在监控界面上，我们就能清晰地看到一个请求的完整生命轨迹，哪个服务慢了、报错了，一目了然,排查效率大大提升。

最后还有个文化上的坑，团队协作成本高了”。（来源：技术总监在季度总结会上的反思）以前一个大团队维护一个单体，沟通成本低，现在拆成小团队各管一摊，每个服务怎么设计、接口怎么定，都得反复沟通，一不小心，A团队改了个接口没及时通知B团队，线上就直接报错，我们后来定了很多规矩，比如接口版本化管理，不允许破坏性变更；建立了一个统一的API文档中心，所有接口变更必须登记；还定期开跨团队的技术评审会,让大家信息同步。

所以你看，微服务和云应用确实能提升开发的灵活性和系统的可扩展性，但背后这些效率上的坑，真是说不完，每一个提升的效率点，几乎都伴随着另一个需要花费精力去填的坑，关键就在于，我们得不断学习、总结妙招，用合适的工具和流程把这些坑给填平了，才能真的享受到技术变革带来的红利，说白了，就是从一个“泥瓦匠”（砌单体大泥球）变成了一个“城市规划师”，光会盖房子不行，还得懂交通、水电、消防这些系统工程。