就在今年，Atlassian这家澳大利亚的协作软件公司坦白了个真相，它花了整整四年时间来理顺内部乱七八糟的依赖关系，结果还是没搞定——不过现在他们觉得那些问题都还在掌控之中。正如高级工程经理Andrew Ross在周二的帖子里说的那样，Atlassian运营的平台特别庞大，有上千个各式各样的服务，大部分都是通过自家的编排系统Micros来管的。Micros要管着两千多个服务，每天干五千多回部署的活儿，手里攥着四万多个DynamoDB表和八万多个Amazon RDS表，还要伺候着三百万个lambda函数。公司里还有个重要的玩意儿叫Artifactory，这是个私有的Docker注册表。在2021年的时候，Atlassian就是用Micros把Artifactory给部署了上去，结果就是Micros平台在部署和运行的时候还得靠Artifactory这根大腿。这意味着只要这俩家伙里有一个趴下了，另一个立马就得歇菜。这事儿可把他们折腾坏了，毕竟他们是家SaaS公司，正忙着把客户从本地往云上赶呢。为了解决这个困局，他们搞了个叫持续PaaS恢复（CPR）的项目。 随着项目往下走，他们发现想把所有依赖都杀光是没戏了。所以他们把精力都放在了那些最难恢复的依赖死结上。到了2023年，他们搞了一场桌面演练来模拟灾备，假装有6.5天的恢复时间，好让大家都明白这里面的风险有多大。Ross发的图里绿的就是已经恢复的服务，红的就是因为卡壳还没起得来的。你看左边的图，只有三个服务是活的；右边的图里倒是多了不少绿色的服务。 现在他们把平台改造成了Ross所说的那种层级结构。“我们决定把云基建分成好几层，底层的东西少依赖点，上面的多依赖点。”Ross写道。这个新架构也没把所有依赖都砍掉，毕竟大家都明白想完全不依赖谁是不可能的。相反，大家学会了怎么跟这些依赖相处的法子，还遵循了几个原则。 他们把Artifactory从Micros挪到了Kubernetes上，干掉了一个大循环；又搞了个叫Atlassian Platform Deployer（APD）的新系统来配低依赖的配置。APD拿AWS CloudFormation当引擎帮着干活。有了这套新东西之后，他们把Micros也迁到了APD上面去。虽然还是有内部的循环依赖在捣乱，但总算干掉了几百个这种毛病。现在感觉平台稳多了、也更好恢复了。 他们必须这么干才行，因为最近刚宣布要把本地产品给砍掉，把所有客户都弄到云端去。你想想看Cloudflare和AWS之前那次大崩溃不就是因为循环依赖惹的祸吗？这时候把客户往云上赶会不会让他们觉得太冒险了呢？