先给大家讲个小故事。如果给你一个两室一厅的毛坯房，让你设计自己的世界，相信你一定有很多想法：不同的区域可以有完全不同的设计。家具的摆放要兼顾美观和实用。储物空间要满足以后连续购物的需要。电源插座的数量和位置要符合市场上不断出现的新电子产品...装修完成，住进去的感觉真的很棒，一切都是按照自己的想法设计的，完美。然后，新的需求来了，你们结婚了，这个房间又添了一个新主人。TA的想法未必和你的完全一样。TA也有很多东西要放，也有自己喜欢的生活方式，所以你的部分设计已经开始改变原来的用途，甚至可能需要重新装修。随着人数的增加，需求也会不断变化。你有了自己的宝宝，开始大量购买婴儿用品，奶粉、纸尿裤、婴儿床等等。以现在年轻人的工作节奏，估计两边的老人都会被叫来帮忙照顾孩子。老人的加入，也会给房屋的使用增加更多新的需求。即使你很早就想到了这一点，相信你也抵挡不住新需求的冲击。你一定遇到过想找东西却找不到的场景，打开衣柜和床下的储物空间，里面乱七八糟的让你受不了。架构混沌软件架构就像我们的房子。随着各种需求的增加，我们划分的各种组件不再像原来设计的那么简单，而是变得杂乱复杂。通常，可能有以下表现形式：系统稳定性差，架构损坏。初期表现多从用户体验端体现，如不断收到用户投诉，被投诉功能无法正常使用等。用户感觉就像在一个大而杂乱的存储空间中寻找一个项目。不仅耗费大量的时间和体力，而且找到后也不确定能否正常使用，体验很差。当软件设计变得复杂时，架构设计、数据质量和数据关系都会变得复杂。你甚至会惊讶地发现，当一个请求来自前端时，后端需要十几个服务的配合，通过几十个跨服务调用才能完成。在这种情况下，性能和稳定性对用户体验的影响是致命的。.系统扩展性差对于开发团队来说，上面提到的接口可能会成为噩梦，几乎没人敢碰，因为谁也不知道改了会不会有新的问题。这个问题有很多原因。比如服务之间存在循环依赖，服务中过多的冗余数据需要同步更新，部分服务在边界外承担了很多职责。也有多个服务由于设计不合理而无法组合完整处理一个业务，数据一致性问题时有发生。这些设计的复杂性对可扩展性影响很大，会牵一发而动全身。最后没人敢改，只能重新发明轮子。就像同一种户型，不同的设计和用途也会使结果完全不同。如果储物空间设计不合理，功能区域划分不合理，东西就会堆得满地都是。总觉得空间不够用，到最后也懒得收拾，也不能再添置物品和家具。我只能希望另一个。更大的房子需要重新设计，但这往往是一厢情愿的想法。数据准确性差数据是业务的核心。业务是各种数据变更和迁移的逻辑组合。数据质量和一致性直接影响业务的准确性。在分布式系统中，做到这一点并不容易：相关集成流入系统的数据质量差，脏数据很多，导致很多进程无法进行下去。业务逻辑设计复杂，导致一个操作同时更新大量数据。如果没有分布式事务等特殊手段的保障，很容易导致一个服务的数据过时。update，其他服务的数据没有更新导致业务异常。系统可用性差。系统集成也是最有问题的场景之一。第三方集成系统出现问题，往往会引起一系列的连锁反应，导致系统关键业务的失败。遇到这种问题，我既委屈又无奈，但归根结底，我还是没有从设计上隔离其他系统对自己的影响。每个系统面对的用户不同，因此对系统的要求也不同。对于一个要求比较严格的系统，它需要保证的响应时间和并发性可能会比其他系统高很多。当请求量较大时，支撑系统可能无法及时响应，导致核心业务系统无法正常提供服务。是一种普遍现象。此外，基础设施层面的异常也是导致系统可用性下降的非常直接和关键的原因之一。怎么就乱了？以上问题不是任何架构师都愿意面对的。但是，架构逐渐变得复杂且难以维护。从长远来看，这是一种必然趋势，但究竟是什么原因使这种趋势不可逆转呢？这里暂且不谈人员能力的问题。虽然这个问题不容忽视，但在讨论当前话题时，我们假设团队的开发人员正在尽最大努力确保架构和代码的整洁，然后再看看还有哪些因素导致架构逐渐变得混乱并且复杂，然后可以采取一些措施来延缓架构的腐败。语境缺失造成的认知低下可想而知。当一个系统只有一个服务、几万行代码时，任何一个开发者都可以花一段时间去理解和记住其中的逻辑细节。当业务需求发生变化时，开发人员无需任何研究就会设计出解决方案，甚至可以立即与其他开发人员讨论解决方案的合理性。再想象一下，当业务不断增长时，系统逐渐变得复杂，服务数量膨胀到几十个甚至上百个。我相信没有一个开发者能够解释清楚所有的逻辑细节，甚至很难找到一个能够解释清楚的开发者。他最熟悉的服务的所有实施细节。因为当业务变得复杂时，需要多个服务协同完成，逻辑链条很长，人的大脑容量毕竟是有限的，系统不断增长的知识会逐渐超出人的记忆范围.对于一直在做这个软件系统的开发者来说是这样，那么对于新开发者来说，可以想象他们的业务和系统知识会更少，更难理解原来的脉络和决策原因逻辑设计。项目人员的更换是不可避免的。这种替换将使团队成员的上下文知识越来越少。这种趋势也是不可逆转的。上下文不足和对系统的理解有限很容易导致设计和决策出现问题，从而加速系统的复杂化。边界不明确的大型系统设计系统的架构受到生产它们的组织的通信结构的限制。——《康威定律》随着软件系统越来越复杂，被拆解的服务也越来越多，但是如果做这个系统的开发人员还是一个团队的话，根据康威定律，这个系统的架构会趋向于一个整体而言，各个服务各司其职，并不会像想象中那么明确。就像在自己的房子里，屋主可以随意摆放自己的东西；但是在合租的房子里，肯定是有界限的，即使有公共空间，公共空间也是有规矩的，越过界限就会变得很棘手。因此，当一个系统逐渐变得庞大和复杂时，如果系统的各个组件没有很好地隔离，组件之间的界限只会越来越模糊，从而增加组件的复杂性。耦合的程度使得系统更加复杂，这与负责系统的组织结构有很大关系。软件系统发展演进的驱动因素有很多，但在大多数场景下，系统比较复杂，要根据特定的需求开发特定的功能，这类似于做项目的方式，每次都有明确的目标，并且大部分的程序也是为了这个目标而设计的。做项目的方式对系统最直接的影响就是需求的一致性。许多不同的项目在同一个系统上工作。为了解决不同的问题，简单的叠加功能缺乏对这个软件系统的整体认知和规划。.与做产品不同，每个产品都有一个愿景和一个要解决的核心问题。任何不符合愿景或不能帮助解决核心问题的需求都是伪需求，不应该添加到这个系统中。因此，对于一个作为项目推进的软件系统，随着项目的不断推进，多个不相关或未考虑的需求叠加在系统上，会不断增加软件系统的复杂度。小结就像开头的故事一样，软件系统就像一个不断有人居住的房子。随着需求的不断增加，它会变得复杂和混乱。这种趋势是不可避免的，这种混乱的状态会直接影响到系统的使用者和维护者，无论是作为用户还是作为开发者，体验都很差。但是当我们意识到上述因素会使系统复杂化时，我们仍然可以采取一些措施来尽可能避免这些因素的发生，或者反过来利用这些因素采取一些逆向措施，使系统能够维持一个更长时间的健康状态。
