第05课:总结

第05课:总结

本文作为该课程的最后一部分,对该课程涉及的知识点作一个简单回顾和梳理。

系统架构分解

在系统架构分解这一部分大概讲解了系统架构所包含的内容。当我们审视一个系统时,我们需要知道它的“重要决策”包含哪些方面,每个方面涉及哪些内容,需要以什么样的形式去描述。

详细介绍每种架构的内容及方法显然已经超出本文的范围,你如果感兴趣可以去了解一下 TOGAF、eTOM,当然还有应用架构的 4+1 视图等,都是我们用来做架构的有效的方法论。

我们在本教程中一直强调方法论和架构的治理。因为只有做到有效的治理,你的架构才能进行持续的可控的演进,确保在架构演进的同时,系统的健壮性和有效性不受影响。

还有,你也应该注意到,部分架构知识本教程并未涉及到,如基础设施层,它同样非常重要,也有很多需要关注的问题,只是与本教程主要谈论的松耦合关系不大,因而没有提及。

还有就是对松耦合的定义,我们一定要从广义上来认识它,在架构的各个方面,都会或多或少涉及到松耦合,有业务上的耦合、数据上的耦合、系统/模块上的耦合、部署上的耦合等等。而我们需要做的就是发现各层面的耦合点,找到合适的解决方案。当然,实际工作中,可能不是由一个人去承担这所有工作,这又需要各个岗位的协调和沟通。

业务架构及数据架构松耦合

在业务架构和数据架构部分,我们主要讲了如何分层去划分业务过程。通过对业务过程的分层管理,可以实现以下目标:

  • 满足不同利益相关者的需求,如 CxO(诸如 CEO、CIO、CTO 等等),他们并不关注每个服务的详细实现,他们只需要直到核心业务过程的高层分解即可。而对于设计人员和开发人员,他们则需要知道详细的业务流程,通过提供不同层级的视图,可以满足他们各自的需要。

  • 使得业务过程变更可控,通过业务过程的分层,我们很容易知道业务过程概貌。当业务过程发生变更时(尤其是核心业务过程),它会影响到不同层级分解视图的变更。通过先在高层视图进行变更评估,然后逐步分解传导到低层视图,这种方式使得变更的影响范围可控。

  • 这种逐层分解的过程,有利于你以参与角色、核心过程作为基础,逐步延伸业务过程和数据模型,以提供更完善的功能支撑。因为只有当你对业务过程有一个正确的全局观时,才会做到业务架构的逐步演进。

  • 良好的业务分层和管控,会给应用架构以正确的指导。通过正确的业务过程分解,我们会提早发现一些对业务处理和数据的技术性要求。应用架构以此作为目标进行构建,避免后期出现应用架构无法满足(或者通过不断调整才能满足)业务需求的情况。例如,业务分层明确了系统和模块的边界,那么在业务过程中,系统间如何通讯?实时性要求如何?需要哪些数据?这些都可以作为应用架构的参考(通过分析“业务流程”部分的输出结果,我们不难发现各系统都需要哪些接口通讯。)。

  • 通过业务过程的分解,我们可以以参与角色、核心模型、核心模型附属模型、边缘模型的顺序推演出我们的数据架构,确保数据架构可以有效支撑业务场景。尤其是在产品初创阶段,这种方式可以有效避免开发过程中频繁变更数据模型。后期的变更不仅极易使得数据模型失控,而且也导致数据架构和逻辑/物理实现不一致。

技术架构松耦合

技术架构松耦合主要解决技术架构日益臃肿的问题。尤其在 Java 平台,随着依赖的第三方框架的增多,由第三方框架导致的传递性依赖会使得各种库的版本极易出现冲突。因此看似可以随意组合的主流中间件框架,由于一些通用工具库(如日志、XML、JSON 等)的版本问题,会使得你不断调整各个框架的版本,以期达到一种脆弱的有效性。

除此之外,我们应该致力于使得产品中的第三方框架尽量精简,去除那些不必要依赖库。这样不仅会大大降低发布包的大小(一个功能很少的产品的发布包都需要几十兆,这是不合理的),也会减少由于不必要的配置而引入系统运行问题的风险。

本教程主要从两个层面出发:

  • 第三方库及集成代码的松耦合管理。通过 Maven 等管理工具,我们可以将经过验证的第三方库和模块化的集成代码划分为不同的应用类型。当构建产品时,根据应用类型,自动完成技术架构的搭建工作。

  • 静态文件的管理。主要是如何管理依赖的第三方 JS 库、CSS 等资源。

  • 手脚架的管理。严格的说,手脚架不属于产品发布包中的一部分,但是它可以包含在技术架构中简化我们的开发工作,将开发人员从重复、单调的工作中解放出来。

开发架构松耦合

开发架构的松耦合主要包含两部分。一部分是我们常见的 API 松耦合,你可以根据自己的具体情况,选择适合自己的方案。

另一部分是模块的松耦合,主要指如何将各个模块的配置、资源文件进行分解,避免其相互依赖。 这样做有几点好处:

  • API 松耦合可以降低模块之间功能的相互影响,这也是“松耦合”带给我们的最直接的好处,不仅缩小了变更范围,也减少了变更导致的意外缺陷。

  • 模块的松耦合可以使得模块做到独立的启动。这样做的好处是,使得模块更易于测试和部署。若要实现部署架构的松耦合,这部分是必须要做的。

对于模块的松耦合,大多还是利用了嵌入式服务器和 Servlet 规范的模块化支持。这也是成本最低的一种方案,因为相对于你自行设计的方案,Servlet 规范更健壮而且天然的适用于各种应用服务器(而且既然已经有了现成的方案,我们又何必重新发明轮子呢!)。

部署架构松耦合

在部署架构松耦合部分,我们只是简单的列举了几个场景。但是借鉴这几个场景,可以使得我们的应用系统实现模块任意组合打包和部署。

本部分讨论的部署架构并非最先进的,但也不能说是已过时的,主要还是要看你的应用场景,并不是所有场景都适合诸如微服务、无服务等架构,甚至很多场景都不适合,毕竟软件涵盖的行业和应用类型数不胜数,而我们看到的代表先进架构理念的产品只占了这些行业和应用类型的很少一部分。不要为了技术而技术,否则你的应用的可用性会受到极大的影响。

对于绝大多数应用,如果你做到了模块的任意组合打包及部署,那么往更高级架构升级时,相信也不会很困难。

小结

至此,本课程的所有内容已经结束,如果它能为你的应用系统架构工作带来些许帮助,那么对我们来说将会是非常欣慰的事情。限于文章的篇幅,有些方面我们只是概要讲述,并未详细展开,如果你原意就架构的某个方面与我们进一步探讨,也可以在本课程的读者圈给我们。由于文章编写较为仓促,如果内容有何纰漏,还请及时告诉我们,在此表示万分的歉意。

上一篇
下一篇
目录