刚哥带你参加国际顶级技术会议 - GOTO 2019 柏林 - “刚刚好”的软件架构

原创
2020/06/04 06:57
阅读数 715

今天,刚哥要带来的去年在柏林举行的GOTO2019的一场关于架构的分享。

演讲者Stefan Tilkov是INNOQ的创始人之一,这场分享的主题是“刚刚好”的软件架构。这这场分享中,Srefan利用一些实际的用户案例来探讨什么是刚刚好的软件架构,非常值得我们学习。

软件架构的定义

首先什么是软件架构呢?

这里最值得注意的是Grady Booch提到的,架构表示重要的设计决定,这些决定定义了系统,重要性是以改动的代价来衡量的。刚哥以为,软件的架构和软件的生命周期息息相关,好的架构应该能够服务整个软件的生命周期,为未来可能发生的变化和演进提供强有力的支撑。

架构不是负责人告诉其他人该做什么的前期活动, 架构是系统的属性,而不是对预期设计的描述。

架构是系统的属性,你的系统决定了你的架构,而不是你的架构描述了你的系统。

并不存在最好的架构,就像下面的这些车子。

软件产品有很多的质量属性,不同的产品需求引入不同的质量属性,不同的质量属性定义了不同的上下文环境,也就会有不同的架构选择。

如下图所示,我们可以从两个规模维度来分析软件系统的,水品维度是系统的复杂性,垂直维度是系统的用户数量。不同的系统从规模的角度来看,处于不同的位置。

所以,离开上下文环境来说,并不存在所谓“好的”或者“坏的‘软件架构,架构设计需要考虑特殊的质量属性。

下面,就从一些实际的案例来看看。

案例一:不可扩展的扩展性

第一个案例是一个零售业的电商平台的例子。

上下文环境

  • 平台服务全球用户
  • 服务包含Catalog/CMS/Shop
  • 多租户
  • 高度客户定制化的需求

该平台的用户分为两类,一类是小用户,使用一些常见的通用功能,还有一类的大用户,需要非常特殊的客户定制功能。

我们从成本的客户定制化两个角度来看,对于小的用户而言,只需要提供一些通用的功能,而对于一些大用户而言,需要提供非常特殊的用户定制,当然这样做带来相应的成本的提升。从实际的实施来看,该系统提供了一个折衷的方案,提供了一些定制化的功能,希望同时能够服务两类用户。其实这样的设计既不能满足大用户实际的定制需要,对于小客户而言也没有实际的价值。

从这个案例我们学到的是:

  • 如果你的设计希望满足所有人的需要,那么最终可能谁的需要也满足不了。
  • 高度定制化的代码往往优于复杂的配置。

 

案例二:危险的细粒度

第二个案例是一个大规模B2B食品零售商

上下文环境

  • 新上线公司级的商铺和物流系统
  • 有200+的开发人员

架构决策是采用微服务的方式构建产品,结果是不同的团队之间有很多的耦合的细小的服务。这些服务变得很难管理。

以订单服务为例子,所有的其他的服务都会依赖订单服务。结构订单服务耦合了所有其他服务的逻辑。

问题来了,为什么你要把系统切割成很多细小的,分布的,不可维护的碎片呢?

答案是Netflix,Netflix采用微服务架构取得了巨大的成功,但是,不是每个产品都是Nextflix,要构建分布式的可扩展的影音服务。

更恰当的架构是这样的:

从这个案例我们学到的:

  • 小的并不一定好
  • 在团队的界限之内进行重构和优化,比从全局来做要容易
  • 忽略组织架构的特性来构建架构是很危险的

案例三:系统是动态的

第三个案例是一个大规模的保险系统

上下文环境

  • 模型驱动的设计
  • +100的开发人员
  • 每年两个release

该项目的开发过程中存在一个两周的模型设计过程。

骨灰级的程序员大概还记得rational rose,那个曾经非常火爆的建模工具。

其中一个版本,需要把一个模型的某一个字段改名。

这个字段的修改是维护在一个庞大的Excel表格中,可以想像这个修改会带来的代码的变动,就像噩梦一般。因为模型的所有其他工作的基础,模型的改变是你绝对不想触及的东西。

从这个案例我们学习到的:

  • 中心化的责任会是痛苦的 (这里例子了就是建模的人)
  • 当系统的规则很刻板的时候,开发人员会采用一些迂回的方案
  • 你所习惯的东西不代表它是正确的

案例四:自由式的架构

第四的案例是一个零售业的电商

上下文环境

  • 100-120个开发人员
  • 10个自包含的团队

如下图所示,我们常常说的系统的解耦合往往适合开发人员的数量相关的。

随着开发人员的增加,我们往往需要结偶的方法,模块,组建,服务甚至系统。

从分层的系统演变为包含子系统的系统。

在这里案例中,架构设计是引入前端的微服务架构。

但是问题也随之而来, 该产品的执行策略是一种自由的方式,而该自由方式带来了如下的问题

  • 缺乏开发标准导致UI集成的低效
  • 大量API风格,格式,文档的差异导致了额外的工作量
  • 虽然不存在中心化的前端UI组件,但是存在一个中心化的前端UI团队, 该段对成为了系统的瓶颈

从这里案例我们学到:

  • 你无法决定不定义架构,如果你不积极的去创建它,它会自己出现,准备好去应对它。
  • 要明确多样性和混乱的界限
  • 极度解耦合的系统需要少量的规则,但是这些规则需要强制执行

案例五:像癌细胞一样生长

第五个案例是一个独立财务服务提供商

上下文环境:

  • 30的开发人员
  • 公司有20年的历史
  • 该产品非常成功

刚开始结构比较简单,使用orcale数据库和Orcale Forms App。

随着产品发展,他们决定改进架构,引入Java/JSP Web引擎

然后系统引入了.net的Web技术

随后,他们收购了另一个公司,所以有了两套系统,但是他们决定使用同一套数据库系统。

随着系统演进。更多的数据库被引入。

最为有趣的,他们用C++实现了一个加密的算法,但是该算法出错了,但是没有办法修复,因为数据已经用出错的算法加密了。

但是因为产品的商业上很成功,于是没有人介意这些架构上的问题。系统像癌细胞一样野蛮生长,随着他的长大,清理也变得非常困难。

从这个案例我们学到:

  • 成功的系统可能拥有糟糕的架构
  • 缺乏管理的演进可能导致混乱
  • 不要害怕引入轻微的架构约束

案例六:利用少量的智能来改善系统架构

最后带来一个成功的案例。一家拥有多个COTS系统的银行。

上下文环境:

  • 高度私有化的集成方案随着厂商需要退出使用
  • 利用开源解决方案替代已有的商业解决方案

系统主要的挑战是存在很多的集成的需求。

他们利用消息总线,很好的解决了这个问题。

从该案例我们学到的:

  • 智能端点和傻瓜管道
  • 定制化的价值优于通用解决方案
  • 带有蓝图的微架构

总结

Stefan最后做出了如下的总结:

  1. 不要害怕架构
  2. 选择最简单的可工作方案
  3. 创建可演进的结构
  4. 管理你的架构演进
  5. 不要引入路障,关注价值的创造

 

刚哥的解读,该演说利用一些实际的案例来讲述什么是“刚刚好”的架构,其中一些问题是我们在软件开发过程中经常会遇到的问题。很具说服力。但是因为时间的原因,细节讲述的比较少。我这里把大体的内容带给大家,大家有兴趣的化可以去看原视频。这里有PPT

 

 

 

展开阅读全文
加载中

作者的其它热门文章

打赏
0
0 收藏
分享
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部