一、架构的定义

　　所谓一千个架构师中有一千种“最好的架构”模式。

　　“架构”是我们行业中非常普遍的词，表示它也必须是经过长时间磨合后形成的词。 架构一词的含义是什么？ 解决什么问题？ 只有理解了这两个问题，我们才能设计出良好的项目结构。

　　我认为架构类似于绘制房屋设计。 当我们第一次建造一间只有一层的小房子时，我们拍了一下片刻。 我们有了一个大概的主意就开始着手建设。 在某些情况下，它不会出现。 但是，当您要建造架构物时，拍打额头的方法此时可能仍然有用，但是由于尚未仔细考虑，因此建造不可避免地会出现问题。 此外，建造架构物和建造一层平房所需的团队规模肯定是不同的。 每个人都有不同的标准。 如果没有统一的规范，可以想象最终结果。 因此，结构是设定规则和限制。 权衡各方的得失后，这是“最合理的决定”。 它指导团队中的每个人在意识形态水平上达成共识，以便最终产品由一个人完成。 结果一样。 此外，它还具有控制复杂性，改善团队协作，降低成本等功能。

　　在软件开发中，体系结构的意义不仅在于团队要达成共识，因为我们工作的本质是制作支持业务发展的更好的软件产品，因此体系结构也基于业务体系结构。 我认为良好的结构可以提前1到2年预测业务发展。 这样，可以支付合理的价格来换取技术领先的业务增长的影响。 我相信，大多数留在中小型公司的人都应该经历过被生意推开的时代。 每天，他们都会卡在这里，挂在这里，并在这里报告错误。 当我们遇到这些问题时，该花时间考虑当前体系结构是否存在问题了？

　　二、如何开始设计一个架构

　　进行体系结构最重要的一点是上述业务适配。 任何不基于业务去做异想天开的体系结构的流氓?

　　体系结构不像编写代码，对是对，对错是错，没有对错，这是一个选择的过程。 当我们从0开始构建架构时，确实更加困难。 尽管一开始很难做，但是良好的开端等于成功的一半，这将为我们的下一个工作打下坚实的基础。

　　让我们解释一下作者是如何从头开始亲自构建架构的，以供您参考和研究：

　　1.结构是整个过程->过程的一部分。 首先，有必要弄清楚整个公司/组织为外界提供的服务是什么？ 这是最高级别的战略结构，一旦确定，基本上是很难或不可能更改的。

　　2.将解决方案划分为每个部分(例如SOA的特定服务)。 例如，根据公司的组织结构或产品。

　　3.找到每个解决方案的核心功能和支持功能。 并形成业务概览图。

　　4.分开很长时间，再分开很长时间。 根据当前实际资源情况做出最终决定。 这是整个过程中最耗时的一点。 它决定了体系结构的复杂性和开发成本。 该方法包括但不限于提取可重用函数，组合函数，以更细粒度划分函数以提高可重用性等。 所有这些决定必须是“正确的”。 不要盲目跟随微服务的风潮！ 不要盲目跟随微服务的风潮！ 不要盲目跟随微服务的风潮！ 重要的事情说了3遍。 服务粒度越细，呼叫链接越复杂，以及它带来的开发成本是否适合团队，这是需要作为架构师考虑的一点。

　　5.在每个功能块之间建立协作模式，包括但不限于通信模式，通信协议，依赖关系等。

　　6.最后，这些应该形成最终的架构概述图，这可以帮助从更高的角度考虑架构的演变。 如果要重新架构现有项目，那么我们需要在上面的思考过程中对现有项目结构进行整理，作为参考信息的一部分。

　　三、一个好架构的特点

　　首先，您必须从心态上具有手工艺的精神，因为软件体系结构和房屋建造仍然有所不同。 一开始它没有到位。 一个好的设计必须被反复修改，从简单到复杂的循环验证，以及连续的抛光。

　　在的方向上，我认为有以下几点：

　　1.文档：无论是整个生命周期还是整个生命周期的一部分，都必须有充分的文档记录。 更改的来源包括但不限于BUG和要求。

　　2.高可用性：为了尽可能提高软件的可用性，我认为每个操作员都不愿意看到他的工作无法正常进行。 黑盒和白盒测试，单元测试，自动化测试，故障注入测试，提高测试覆盖率等逐步实现。

　　3.安全性：在组织运营过程中生成的数据具有商业价值，确保数据的安全性也是当务之急。 为了避免诸如XX门等丑闻。 加密，https等是常用方法。

　　4.可扩展：软件的设计坚持低耦合的概念，在合理的地方注意抽象。 它促进了功能更改，添加和应用技术的迭代，并支持在适当的时候对体系结构进行重构。

　　5.快速迭代：拥抱变化并抓住战略机遇。

　　6.高度自治：为了更好地支持第4点和第5点，每个功能都具有高度自治的好处是可以快速迭代，无论是功能迭代还是技术迭代，其影响 在整个系统上最小化。

　　7.高重用性：为了避免重复工作并降低成本，我们希望重用先前的代码和先前的设计。 这是最依赖于架构环境的。

　　8.可验证：一个好的框架需要考虑各种特殊情况，并且可以进行具体验证。

　　四、做架构中的误区

　　做任何事的时候需要不断的跳出原来的思维角度重新审视，这样才能避免陷入泥潭。列出几个我能想到的误区：

　　误区1——架构专门由架构师来做，业务开发人员无需关注：架构的再好，最终还是需要代码来落地，并且组织越大这个落地的难度越大。不单单是系统架构，每个解决方案每个项目也由自己的架构，如分层、设计模式等。如果每一块砖瓦不够坚固，那么整个系统还是会有崩塌的风险。所谓“千里之堤，溃于蚁穴”。

　　误区2——架构师确定了架构蓝图之后任务就结束了：架构不是“空中楼阁”，最终还是要落地的，但是架构师完全不去深入到第一线怎么知道“地”在哪？怎么才能落的稳稳当当。

　　误区3——不做出完美的架构设计不开工：世上没有最好架构，只有最合适的架构。我们需要的不是一下子造出一辆汽车，而是从单轮车 --> 自行车 --> 摩托车，最后再到汽车。想象一下2年后才能造出的产品，当初市场还存在吗？

　　五、结语

　　架构之路任重而道远。程序设计和架构设计是互通的，每个人都可以从设计好一个程序往设计好一个系统架构前进。