本文主要是介绍画好一张架构图有多难？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
果芽科技
GUOYA TECHNOLOGY
致力于写大家都能看懂的、有深度的
技术文章
04/2024
经过梳理与整合，我发现我们当前的架构呈现出一个洋葱型结构，从外到内分别是应用层、领域服务层和业务基础能力层。尽管这个基础架构方向是正确的，但绘制出来的架构图却显得杂乱无章，仿佛是我早晨未梳理的头发。
02
架构图的挑战与机遇
绘制架构图之所以困难，一方面是因为我个人的绘图技巧有待提升，另一方面则是由于当前架构本身的复杂性。不过，这也为我们提供了一个机会：通过改进架构图，我们可以更好地理解和优化整个系统。
为了迈向更加整洁的架构，我们有必要回顾并遵循一些关键的设计原则。
02
整洁架构的规划设计原则
首先，我们要避免不必要的相互调用和循环调用。这种调用关系违反了设计原则，可能对系统的稳定性和扩展性造成潜在影响。当一个系统内部的相互调用过于频繁时，如果负责团队分开，他们可能会深感架构的痛点，并寻求服务自治来重构和解决问题。
其次，为了确保架构的稳定性，我们应尽量避免跨层级调用。当然，如果出现了一些跨层级调用但并未引发实际问题，且这些功能没有迫切的迭代需求，我们可以暂时保持现状，等待相关需求出现时再进行整体优化。关键在于，绝不能让内层稳定的模块为了适应外层的接口而频繁修改，而应当补充中间缺失的逻辑层次，让中间层来处理这些差异。
此外，随着服务的演进，其定位可能会发生变化。例如，一个领域服务可能会逐渐变得更加稳定，适用于更多的服务，从而演变为业务基础能力。这种平滑演进的方式比完全重写或重新设计架构更具投资回报率。我们应该有一个长期的发展蓝图，但同时也要注重逐步实现。
02
架构图的梳理与优化
在梳理架构图时，我们还需要关注潜在的单点故障。无论是软件层面的负载均衡还是硬件如F5的主备模式，我们都应思考在出现故障时如何快速恢复。同时，要梳理系统中的各个模块，评估它们是否具备回滚能力，以及回滚的敏捷性是否满足要求。
另外，同步调用可能降低系统的可用性。Amdhal的同步定律也强调了串行化对性能提升的负面影响。因此，我们需要通过架构图来识别这些潜在的优化空间。
最后，通过架构图识别出风险较高的链路，考虑是否需要采用舱壁泳道等机制来隔离失败单元，从而提高系统的整体稳定性。
04
架构图的展开与打磨
尽管初始的洋葱型架构图显得杂乱无章，但我们可以通过展开它为大家更习惯的方框架构图来使其更加清晰。然而，要进一步优化这张图，需要架构师的不断打磨和改进。这是一个持续的过程，需要我们在实践中不断学习和提升。
05
结语
绘制一张整洁的架构图并非易事，但它是系统检修和设计的关键步骤。通过遵循设计原则、梳理和优化架构图，我们可以逐步迈向更加稳定、可扩展和易于维护的系统。
有人问过我，画出一个公司的整体架构大概要多久。我回答说两天我可以画出一个初版，但是直到最后，我都在不断改进这张架构图：这是一个持续的过程，需要我们不断学习和实践。
PS：在画架构图的时候有个小的注意事项。如果想用图标表示基础组件，一定要配文字，不然很多人、不只是小白，不知道这个表示的到底是什么，识图工具可能也鉴别不出来。谁能告诉我下面这一排表示的是哪些开源组件？
下面这一排就友好很多，不知道的可以根据文字去查。
这篇关于画好一张架构图有多难？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
