Blog

Blog

PHODAL

"微" 害架构

"微" 害架构

“微” 害架构,即微架构以不合理的方式运行着,其表现形式不适当地采用 “微架构”(微服务、APP 插件化、微前端等)技术拆分臃肿的单体应用,导致软件架构进一步复杂化、难以维护,使得原本具有优势的微架构微微出现一些问题。

为什么一个设计良好的架构,会变成一个人人嫌弃的架构?我们可以轻轻松松地列举出这么一些理由:

  • 架构的设计不符合演进的需求。
  • 开始设计时,架构就不合理。
  • 架构本身是合理的,后继的开发者能力不足。
  • 架构本身是合理的,然而开发的过程中走歪了。

关于能力不足导致的架构问题,就不进一步展开讨论。我们主要讨论的是 “走歪了的流程”,它才是导致 "微" 害架构的元凶。在开发能力完备的情况下,架构走向微微不合理的地方,有一个原因是:KPI。KPI 导向的系统架构设计,必然会出现一定的不合理性。

  • “我们的竞争对手采用了微服务架构,你看看我们有没有办法也用这个架构?”
  • “隔壁开发小组的团队使用了微前端架构,我们也上这个架构吧?”
  • “小李啊,听说最近微服务很火啊,你看能不能看到我们的项目上?”
  • ……

如果只是吐槽 KPI,那么这篇文章对于读者来说一定是没有价值的,因为 KPI 是一定要有的。架构是不是最好的不重要啊,重要的是大家都满意——领导满意了,可以多涨工资;团队采用了,可以向外宣传,吸引新成员。

那么到底是怎么样产生的 "微" 害架构?从定义上我们可以知道,架构本身应该是合理的,只是出现了点问题。问题的原因有多种多样,如没有因地置宜地实施架构—— A 项目有 50 个后端开发,后端由 20 个微服务组成;B 项目有 10 个后端,也由 20 个微服务组成。每次上线的时候,不得不出动所有的人,上线到半夜才算完成。然后,发了个凌晨 4 点的朋友圈。

而在走歪之前,让我们先了解、回顾一下再有系统的架构形成。

架构的演进

回过头来看,大型项目的架构演进,无非就是:

  1. 我有了一个 Idea,快速地设计出了原型 1.0 版本,并推向了市场,效果还不错,赚到一些钱了。
  2. 市面上的竞争对手越来越多,为了赢得这场战争,我们在 2.0 版本系统里添加了越来越多的功能,一个臃肿的单体应用。
  3. 随着时间的推移,我们添加新功能的难度越来越大,于是我们设计出了 3.0 版本的系统——在今天这个节点里,就是微服务架构。

这就是《Linux/Unix 设计思想》一书中所提到的三个系统,毫无维和感:

  1. 在背水一战的情况下,人类设计出了第一个系统。
  2. 专家们在第一个系统的基础上,做出了伟大而臃肿的第二个系统。
  3. 受累于第二个系统的人,设计出了第三个系统。

可故事并不能因此而结束。随着时间的推移,受益于第三个系统的人们,又有一部分组织会回到第二个系统

大部分的组织,会意识到三个系统的存在。于是,在根据 Idea 设计一个新系统的时候,采用了第三个系统的架构,然后出错了——因为他们缺少专家。这里的专家并单纯指技术方面的专家,而是技术专家 + 业务专家,他/她可以是一个懂业务的技术专家,或者一个懂技术的业务专家。架构在底层是由技术实现的,而在顶层则是业务代码实现的。

业务层的耦合直接影响了技术上的耦合。这个困境导致了,技术架构在不断变化。

组织及架构变更

从我毕业到现在,大公司、大组织的软件架构不断地在发生变革。Mobile First、One APP 、中台战略各种口号不断提出、不断修改。线下业务线上化发展的过程中,业务不断发展,导致组织的软件部门本身的膨胀,进一步地便映射到了软件架构上。

再次的,让我们联系到了 “康威定律”:设计系统的组织,其产生的设计和架构等价于组织间的沟通结构。可它并不是在反应康威定律。而是相似的推论:系统的组织不断变化的同时,其设计和架构也相应的在不断地调整。

面对组织结构变化的同时,架构也随着产生了一系列的变化,毕竟:天下大势,分久必合,合久必分。同数据库分库分表一样,既然一个组织的部门已经过于庞大,那就进一步细化。同理之下,软件的不同部分又被拆分到不同的部门之下。而随着不同部门的业务发展,技术栈也因此而越来越难以统一,出现了多样化。而在走向多样化的一段时间之后,用户越来越讨厌一家公司的应用(Web、移动 Web、APP)分散在多个不同的应用上,于是应用又开始进一步走向聚合。

于是在过去的两三年里,我参与了一系列的 “微架构” 相关的系统的开发。参与的是互联网领域的应用开发,所以主要有:

后端拆分。其典型的形式便是微服务,而以微服务的实现来说,不同部门的服务也往往通常是独立存在的,在架构上后台本身也是互不干扰的。只要保证接口 API 是正常的,那么我们并不需要关心其它项目背后的技术栈。将其与 APP 和前端一对比,就会发现其实后端微服务是特别容易实现的。然而,

APP 拆分。APP 由于存在多种容器,便有插件化、组件化、小程序等不同的方案。整个 APP 所承载的代码量,有可能不逊色于操作系统的代码量。跨团队共同在一个代码库开发,并不是一件容易的事,因此只能提供一个 APP 平台,让不同部分的业务可以在上面运行。

前端拆分。大规模前端应用的开发历史,要比 APP 要短得多,但是也出现了一系列的拆分方案:前端微服务化微应用化。前端走向微前端架构的原因,除了庞大的单体应用,还有一部分是要聚合旧的遗留应用。

其中或多或少走过的坑,让我意识到了微架构对于人员素质的要求。对于有些组织来说,其不合理地采用微架构带来的问题,可能比带来的问题还多。

微架构带来的问题

“微” 害架构,即微架构以不合理的方式运行着,其表现形式不适当地采用 “微架构”(微服务、APP 插件化、微前端等)技术拆分臃肿的单体应用,导致软件架构进一步复杂化、难以维护,使得原本具有优势的微架构微微出现一些问题。

在不同的微架构领域里,他们有着不同的原因。在考察是否使用某项技术的时候,我们就会考虑这些因素。而在个时候,我们的第一答案是:“直接使用这种架构,具体遇到什么问题再解决”。是的,现在让我们来戳破这些问题,来看看有没有对应的解决方式?

以下的内容以个人经验、理解为主,可能与项目的情况不同。

后端:微服务到应用

实施过后端微服务的开发人员,想必对微服务也有一系列的看法。在不正确的实施之后,不少的人会对微服务有不满。尽管如此,他/她们都会承认微服务在隔离服务之间的价值。但是当带来的问题远大于收益时,它就变得不值得采用了——要么是问题不好解决,要么是问题解决不了。早在 2014 年,我翻译了一篇微服务代价的相关文章《微服务架构——不是免费的午餐》,其中提到的多数都是技术问题。

在项目上实施的时候,我发现有一些额外的问题:

  • 代码架构。在不同的组织之间,采用微服务架构,对于相互之间都是好处的。但是在一个小型的内部组织里,掌握代码独立的微服务数量就值得考虑了——既然不需要和别人沟通,为什么需要在十多个 repo 间切换??
  • 部署流程。微服务讲究的是独立开发、独立部署,而如果一个微服务如果不能独立部署,有些固定的上线周期,那么部署变成一件痛苦的事。如果在一次 release 计划里,我们需要同时上线十几个服务,就变得……。

那么,在这种情况下,这些开发者就在考虑:是否值得采用微服务架构?而实际上这个问题的本质可能是,是否有独立拆分微服务的必要?

或者采取集成构建的方式,在开发和构建时来独立两个应用,而部署只需要部署一个应用?

客户端:插件化、组件化

(PS:笔者仅有 Android 插件化相关的经验)

APP 的拆分可以分为:插件化、组件化两种方式。插件化是集成构建完后的 APK 包,而组件化(Module)则是集成构建后的模块(lib)。Web 前端的拆分则可以是:微前端、微应用和跨框架组件化几种形式。

不论采用的是哪种方式,每一个微小的部分,最后可以在同一框架内运行。不同的实现方式,稍有有一些区别。有些架构在实施起来很轻松,但是在维护后却变得相当麻烦。而实际上往往有很多的架构在实施的时候就很麻烦,更不用说在后期维护更加麻烦。

业务的价值往往以大前端的形式呈现,因此移动应用在代码的拆分上,往往比后端容易。不论采用的是动态加载、UI跳转、路由或者其它的形式,都 得考虑如何来拆分代码。于是我们就遇到问题了:

  • 一个简单的业务,是否有必要成为一个简单的服务?

这个时候,当我们有一系列简单的功能,那么它们真的要得独立运行。它们是否有必要成为多个简单的组件?他们不能是一个组件来接受多个参数吗?

面对这些问题,我们可以采取合适的代码拆分策略,以方便在未来合适的时候拆分。而限制我们这么做的主要原因是,后期拆分的时候巨大的挑战。

解决方式?可拆分式微架构?

要合并多个后端服务,那么就需要统一它们的技术栈,但是他们的技术栈会是一样的吗?在多数组织里,技术异构是存在的——只存在于少数据服务中。在大多数情况下,他们都是使用同一种技术构建的。同一个语言、一个框架,可以降低学习成本。在一些不易实现特性,如机器学习、深度学习,则使用 Python 等拥有丰富 AI 生态的技术栈来构建。

此时,我们只需要保证可以成功构建即可,如 微应用化 但是一种构建时集成的方式。当然了,我可能又一次的回到锤子定律的坑里了。

而这种方式并不违反微服务的一系列原则,服务自治、专注的服务等等。在需要的时候,诸如我们主要修改的代码在某一个特定的服务里,那么我们只需要拆分出来独立部署。

同理于,APP 插件化和前端微应用化。只是如果没有规范化开发流程,架构之间可能会出现进一步的耦合。

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806

新书《全栈应用开发:精益实践》

这不是一本深入前端、后台、运维、设计、分析等各个领域的书籍。本书以实践的方式,将这一系列的领域及理论知识结合到一起,来帮助读者构建全栈Web 开发的知识体系,并辅以精益及敏捷的思想,来一步步开发Web 应用:从创建一个UI 原型到编写出静态的前端页面;从静态的前端页面到带后台的应用,并部署应用;从Web 后台开发API 到开发移动Web 应用。在这个过程中,我们还将介绍一些相辅相成的步骤:使用构建系统来加速Web 应用的开发;为应用添加数据分析工具来改进产品;使用分析工具来改善应用的性能;通过自动化部署来加快上线流程;从而帮助读者开发出一个真正可用的全栈 Web 应用。同时,我们也将帮助读者把这些步骤应用到现有的系统上,改进现有系统的开发流程。

comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签