一个java架构师是如何设计出一个好的架构的

  一、架构的定义   所谓一千个架构师中有一千种“最好的架构”模式。   “架构”是我们行业中非常普遍的词,表示它也必须是经过长时间磨合后形成的词。 架构一词的含义是什么? 解决什么问...

  一、架构的定义

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

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

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

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

attachments-2020-08-46wGeHiv5f2cfe6eaaf1c.png

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

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

  体系结构不像编写代码,对是对,对错是错,没有对错,这是一个选择的过程。 当我们从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年后才能造出的产品,当初市场还存在吗?

  五、结语

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

推荐阅读:java架构师指南之什么是架构和架构本质

  • 发表于 2020-08-07 15:11
  • 阅读 ( 97 )
  • 分类:技术干货

0 条评论

请先 登录 后评论
JAVA Q&A
JAVA Q&A

171 篇文章

作家榜 »

  1. JAVA Q&A 171 文章
  2. 江南 1 文章
  3. 伯乐 0 文章
  4. 孤存 0 文章
  5. q21164340 0 文章
  6. 赫敏12 0 文章
  7. 子牙 0 文章
  8. 赫敏 0 文章