今天，刚哥要带来的去年在柏林举行的GOTO2019的一场关于架构的分享。
演讲者Stefan Tilkov是INNOQ的创始人之一，这场分享的主题是“刚刚好”的软件架构。这这场分享中，Srefan利用一些实际的用户案例来探讨什么是刚刚好的软件架构，非常值得我们学习。
软件架构的定义
首先什么是软件架构呢？
这里最值得注意的是Grady Booch提到的，架构表示重要的设计决定，这些决定定义了系统，重要性是以改动的代价来衡量的。刚哥以为，软件的架构和软件的生命周期息息相关，好的架构应该能够服务整个软件的生命周期，为未来可能发生的变化和演进提供强有力的支撑。
架构不是负责人告诉其他人该做什么的前期活动， 架构是系统的属性，而不是对预期设计的描述。
架构是系统的属性，你的系统决定了你的架构，而不是你的架构描述了你的系统。
并不存在最好的架构，就像下面的这些车子。
软件产品有很多的质量属性，不同的产品需求引入不同的质量属性，不同的质量属性定义了不同的上下文环境，也就会有不同的架构选择。
如下图所示，我们可以从两个规模维度来分析软件系统的，水平维度是系统的复杂性，垂直维度是系统的用户数量。不同的系统从规模的角度来看，处于不同的位置。
所以，离开上下文环境来说，并不存在所谓“好的”或者“坏的‘软件架构，架构设计需要考虑特殊的质量属性。
下面，就从一些实际的案例来看看。
案例一：不可扩展的扩展性
第一个案例是一个零售业的电商平台的例子。
上下文环境
该平台的用户分为两类，一类是小用户，使用一些常见的通用功能，还有一类的大用户，需要非常特殊的客户定制功能。
我们从成本的客户定制化两个角度来看，对于小的用户而言，只需要提供一些通用的功能，而对于一些大用户而言，需要提供非常特殊的用户定制，当然这样做带来相应的成本的提升。从实际的实施来看，该系统提供了一个折衷的方案，提供了一些定制化的功能，希望同时能够服务两类用户。其实这样的设计既不能满足大用户实际的定制需要，对于小客户而言也没有实际的价值。
从这个案例我们学到的是：
如果你的设计希望满足所有人的需要，那么最终可能谁的需要也满足不了。高度定制化的代码往往优于复杂的配置。
案例二：危险的细粒度
第二个案例是一个大规模B2B食品零售商
上下文环境
架构决策是采用微服务的方式构建产品，结果是不同的团队之间有很多的耦和的细小的服务。这些服务变得很难管理。
以订单服务为例子，所有的其他的服务都会依赖订单服务。结构订单服务耦合了所有其他服务的逻辑。
问题来了，为什么你要把系统切割成很多细小的，分布的，不可维护的碎片呢？
答案是Netflix，Netflix采用微服务架构取得了巨大的成功，但是，不是每个产品都是Nextflix，要构建分布式的可扩展的影音服务。
更恰当的架构是这样的：
从这个案例我们学到的：
小的并不一定好在团队的界限之内进行重构和优化，比从全局来做要容易忽略组织架构的特性来构建架构是很危险的
案例三：系统是动态的
第三个案例是一个大规模的保险系统
上下文环境
该项目的开发过程中存在一个两周的模型设计过程。
骨灰级的程序员大概还记得rational rose，那个曾经非常火爆的建模工具。
其中一个版本，需要把一个模型的某一个字段改名。
这个字段的修改是维护在一个庞大的Excel表格中，可以想像这个修改会带来的代码的变动，就像噩梦一般。因为模型的所有其他工作的基础，模型的改变是你绝对不想触及的东西。
从这个案例我们学习到的：
中心化的责任会是痛苦的 （这里例子了就是建模的人）当系统的规则很刻板的时候，开发人员会采用一些迂回的方案你所习惯的东西不代表它是正确的
案例四：自由式的架构
第四个案例是一个零售业的电商
上下文环境
如下图所示，我们常常说的系统的解耦合往往和开发人员的数量相关的。
随着开发人员的增加，我们往往需要结偶的方法，模块，组建，服务甚至系统。
从分层的系统演变为包含子系统的系统。
在这里案例中，架构设计是引入前端的微服务架构。
但是问题也随之而来， 该产品的执行策略是一种自由的方式，而该自由方式带来了如下的问题
从这里案例我们学到：
你无法决定不定义架构，如果你不积极的去创建它，它会自己出现，准备好去应对它。要明确多样性和混乱的界限极度解耦合的系统需要少量的规则，但是这些规则需要强制执行
案例五：像癌细胞一样生长
第五个案例是一个独立财务服务提供商
上下文环境：
刚开始结构比较简单，使用orcale数据库和Orcale Forms App。
随着产品发展，他们决定改进架构，引入Java/JSP Web引擎
然后系统引入了.net的Web技术
随后，他们收购了另一个公司，所以有了两套系统，但是他们决定使用同一套数据库系统。
随着系统演进。更多的数据库被引入。
最为有趣的，他们用C++实现了一个加密的算法，但是该算法出错了，但是没有办法修复，因为数据已经用出错的算法加密了。
但是因为产品的商业上很成功，于是没有人介意这些架构上的问题。系统像癌细胞一样野蛮生长，随着他的长大，清理也变得非常困难。
从这个案例我们学到：
成功的系统可能拥有糟糕的架构缺乏管理的演进可能导致混乱不要害怕引入轻微的架构约束
案例六：利用少量的智能来改善系统架构
最后带来一个成功的案例。一家拥有多个COTS系统的银行。
上下文环境：
系统主要的挑战是存在很多的集成的需求。
他们利用消息总线，很好的解决了这个问题。
从该案例我们学到的：
总结
Stefan最后做出了如下的总结：
- 不要害怕架构
- 选择最简单的可工作方案
- 创建可演进的结构
- 管理你的架构演进
- 不要引入路障，关注价值的创造
刚哥的解读，该演说利用一些实际的案例来讲述什么是“刚刚好”的架构，其中一些问题是我们在软件开发过程中经常会遇到的问题。很具说服力。但是因为时间的原因，细节讲述的比较少。我这里把大体的内容带给大家，大家有兴趣的话可以去看视频。
这里有PPT ：
https://github.com/gangtao/confshare/blob/master/GOTO2019/2019-10-23-Good-Enough-Architecture–GOTO.pdf
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！