构建前瞻性应用架构的优秀实践.docxVIP

构建前瞻性应用架构的优秀实践 2021-03-27 为什么应用架构如此重要? 通常，应用架构包含了全部的软件模块、组件、内/外部系统、以及构成应用之间的交互关系。明显，结构良好的应用架构，可以确保您的应用能够依据业务和用户的需求进行预期的扩展。同时，好的架构既能够合理地隔离不同的功能概念，又可以在内/外部构成良好的依靠关系。 相反，如下图所示，假如您在针对各种需求的初期设计时，以及后期的变更中，忽视了对于应用架构的合理构建与维护，那么将会导致不同组件之间，依靠关系的错综简单，甚至难以同步与管理。 那么在实际项目中，意面式的架构到底会给我们的系统带来哪些危害呢? · 服务笼统性差：假如未能围围着核心业务概念，实现正确地隔离和笼统，那么服务就会在不同系统之间分散各种业务规章，进而降低代码的结构化和可重用的程度。 ·?难以管理的依靠关系：当组件之间无法被恰当地隔离时，任何针对系统的修改或替换操作，都会产生滚雪球式的效应。也就是说，某一部分的更改，会影响到与之相关联的全部依靠关系。 ·?僵化且运转缓慢的旧系统：假如系统本身就很简单且不机警，那么我们就需要花费更长的时间，通过调整来顺应新的业务变化。而且，假如所用到的技术已经过时，那么随着时间的推移，核心数据与系统会对过时的技术，累积深度的依靠性，从而导致技术更新变得难上加难。 如何构建可扩展的应用架构 为了构建牢靠且可扩展的应用架构，您需要基于严格的定义准绳和完善的设计概念。明显，我们的目标是：既需要支持快速的业务增长和大规模的扩容需求，又需要降低部署的难度并避开昂扬的代码维护成本。因而，我们可以从如下方面考虑应用架构的设计： ·?在全部项目参与者之间达成共识。 ·?支持定义和方案。 ·?持续进行变更。 ·?管理好系统的简单性。 ·?管控与降低风险。 ·?最大限度地削减技术债务(这是任何前瞻性应用架构的最终目标)。 在此，我们引入一个架构画布(Architecture Canvas)概念。作为一个支持和加速架构设计的多层框架，它可以促进对可重用的服务和组件进行笼统。通过保留相对独立的生命周期，架构画布可以最大程度地削减变更所带来的影响，进而使得应用架构更易于维护和扩展。 架构画布的规律组成如上图所示。其中，从下往上分别是： ·?基础层：在该层中，您可以实现全部可重用的非功能性需求。例如：连接到外部系统，或者使用可重用的UI模式与主题库，来扩呈现有的框架服务。 ·?核心层：在该层中，您可以实现各种核心的业务服务。例如：各种围围着业务概念的服务、业务规章、业务实体、业务买卖和业务部件等。您需要让这些服务独立于目标系统，并依据基础服务来笼统出任何可能的整合信息。可见，通过基础层和核心层，您已经隔离出了全部可重用的服务或组件。 ·?最终用户层：在该层中，您可以通过使用基础与核心层的服务，来支持用户界面，以及与用户交互的流程。值得留意的是：为了确保整个生命周期的独立性，处于该层面上的模块，不应为其他模块供应服务。 架构的验证 为确保设计架构的合理性，且不会产生“意面式”的烂尾，下面我将为您供应一些可以遵照的准绳和建议。 1.不要带有横跨三个层面的向上引用 鉴于前文提到的结构化分层，我们明显不应当让与业务无关的基础服务，去依靠核心业务;也不应当让可重用的服务，依靠各种最终用户的接口。此外，向上引用往往会产生一个群集。如下图所示，在该群集中，存在直接或间接链接关系的任何两个模块，都具有循环依靠性。 在上图中，由于模块B可以间接地影响模块A，而模块A也可以间接地影响模块B，因而，这就是一组相互依靠的模块。此外，假如您有另一个正在使用核心服务B的最终用户模块(EU2)，那么它就会依靠整个群集。可见，它们在运转时，不只会占用大量不必要的资源，还会遭到集群中某些模块变化的间接影响。 2.避开最终用户之间的旁路引用 为了确保正确的隔离，并避开最终用户具有不同的生命周期，最终用户模块不应供应可重用的服务。下图呈现了最终用户之间的旁路引用关系。 也就是说，假如最终EU1调用到了EU2，则表明EU1无法独立于EU2，同时他也就不能独立于EU2下面的层级结构中的集群。 3.避开在核心模块和基础模块之间进行循环引用 假如您能够遵照前面提到的两个规章，那么就不必担忧最终用户模块之间可能消灭循环引用。反而，我们应当重点避开在核心模块和基础模块之间，可能消灭的循环引用。此类模块之间的循环引用次要产生于：一些业务概念没能被正确地笼统，进而对代码的管理产生不良的影响。 如上图所示，循环引用多发生在如下两种情况中： ·?A和B之间的连接相当紧密，甚至它们隶属于同一模块(例如，某个订单或订单项)。 ·?依据两个概念之间的既定关系，假如转变一个模块的规律位置，其单方面的依靠关系就会被破坏。例如，合同是由客户产生的，但是客