Apache 的架构师们遵循的 30 条设计原则

本文作者叫 Srinath,是一位科学家,软件架构师,也是一名在分布式系统上工作的程序员。 他是 Apache Axis2 项目的联合创始人,也是 Apache Software 基金会的成员。 他是WSO2流处理器(wso2.com/analytics)的联席架构师。 Srinath 撰写了两本关于 MapReduce 和许多技术文章的书。 他获得了博士学位。 来自美国印第安纳大学。

Srinath 通过不懈的努力最终总结出了30条架构原则,他主张架构师的角色应该由开发团队本身去扮演,而不是专门有个架构师团队或部门。Srinath 认为架构师应该扮演的角色是一个引导者,讨论发起者,花草修建者,而不是定义者和构建者。Srinath 为了解决团队内部的架构纷争和抉择,制定了以下30条原则,这些原则被成员们广泛认可,也成为了新手架构师的学习途径。

Photo by Muyuan Ma on Unsplash

基本原则

原则1:KISS(Keep it simple,sutpid) 和保持每件事情都尽可能的简单。用最简单的解决方案来解决问题。

原则2:YAGNI(You aren’t gonna need it)-不要去搞一些不需要的东西,需要的时候再搞吧。

(小编点评:speculative development的例子可谓俯拾皆是。程序员们对自己说:“我肯定以后会需要这项额外的功能,所以现在就提前把它实现了吧”。其实这是最考验功力的地方,不能闭门YY需要的功能,架构上又要洞察趋势。)

原则3:爬,走,跑。换句话说就是先保证跑通,然后再优化变得更好,然后继续优化让其变得伟大。迭代着去做事情,敏捷开发的思路。对于每个功能点,创建里程碑(最大两周),然后去迭代。

(小编点评:快速反馈,一个“拍脑袋的里程碑”也好过没有里程碑…)

原则4:创建稳定、高质量的产品的唯一方法就是自动化测试。所有的都可以自动化,当你设计时,不妨想想这一点。

(小编点评:一切自动化也要考虑ROI,比如对于特别易变的页面层…)

原则5:时刻要想投入产出比(ROI)。就是划得来不。

原则6:了解你的用户,然后基于此来平衡你需要做哪些事情。不要花了几个月时间做了一个devops用户界面,最后你发现那些人只喜欢命令行。此原则是原则5的一个具体表现。

原则7:设计和测试一个功能得尽可能的独立。当你做设计时,应该想想这一条。从长远来看这能给你解决很多问题,否则你的功能只能等待系统其他所有的功能都就绪了才能测试,这显然很不好。有了这个原则, 你的版本将会更加的顺畅。

原则8:不要搞花哨的。我们都喜欢高端炫酷的设计。最后我们搞了很多功能和解决方案到我们的架构中,然后这些东西根本不会被用到。

(小编点评:老板喜欢ppt?)

功能选择

原则9:不可能预测到用户将会如何使用我们的产品。所以要拥抱MVP(Minimal Viable Product),最小可运行版本。这个观点主要思想就是你挑几个很少的使用场景,然后把它搞出来,然后发布上线让用户使用,然后基于体验和用户反馈再决定下一步要做什么。

原则10:尽可能的做较少的功能。当有疑问的时候,就不要去做,甚至干掉。很多功能从来不会被使用。最多留个扩展点就够了。

(小编点评:产品经理可能是听不进去的,最好采取数据度量说话…)

原则11:等到有人提出再说(除非是影响核心流程,否则就等到需要的时候再去做)。

原则12:有时候你要有勇气和客户说不。这时候你需要找到一个更好的解决方案来去解决。记住亨利福特曾经说过的 :”如果我问人们他们需要什么,他们会说我需要一匹速度更快的马”。记住:你是那个专家,你要去引导和领导。要去做正确的事情,而不是流行的事情。最终用户会感谢你为他们提供了汽车。

服务端设计和并发

原则13:要知道一个server是如何运行的,从硬件到操作系统,直到编程语言。优化IO调用的数量是你通往最好架构的首选之路。

原则14:要了解Amdhal同步定律。在线程之间共享可变数据会让你的程序变慢。只在必要的时候才去使用并发的数据结构,只在必须使用同步(synchronization)的时候才去使用同步。如果要用锁,也要确保尽可能少的时间去hold住锁。如果要在加锁后做一些事情,要确保自己在锁内会做哪些事情。

原则15:如果你的设计是一个无阻塞且事件驱动的架构,那么千万不要阻塞线程或者在这些线程中做一些IO操作,如果你做了,你的系统会慢的像骡子一样。

分布式系统

原则16:无状态的系统的是可扩展的和直接的。任何时候都要考虑这一点,不要搞个不可扩展的,有状态的东东出来,这是起码的。

原则17:保证消息只被传递一次,不管失败,这很难,除非你要在客户端和服务端都做控制。试着让你的系统更轻便(使用原则18)。你要知道大部分的承诺exactly-once-delivery的系统都是做了精简的。

原则18:实现一个操作尽可能的幂等。这样的话就比较好恢复,而且你还处于至少一次传递(at least once delivery)的状态。

原则19:知道CAP理论。可扩展的事务(分布式事务)是很难的。如果可能的的话,尽可能的使用补偿机制。RDBMS事务是无法扩展的。

(小编点评:new SQL了解一下。。。)

原则20:分布式一致性无法扩展,也无法进行组通信,也无法进行集群范围内的可靠通信。理想情况下最大的节点限制为8个节点。

原则21:在分布式系统中,你永远无法避免延迟和失败。

(小编点评:嗯,对,面向fail 设计。但是你的考虑你的用户,你的服务提供SLA。是真的需要7*24*365吗?)

用户体验

原则22:要了解你的用户和清楚他们的目标。他们是新手、专家还是偶然的用户?他们了解计算机科学的程度。极客喜欢扩展点,开发者喜欢示例和脚本,而普通人则喜欢UI。

原则23:最好的产品是不需要产品手册的。

原则24:当你无法在两个选择中做决定的时候,请不要直接把这个问题通过提供配置选项的方式传递给用户。这样只能让用户更加的发懵。如果连你这个专家都无法选择的情况下,交给一个比你了解的还少的人这样合适吗?最好的做法的是每次都找到一个可行的选项;次好的做法是自动的给出选项,第三好的做法是增加一个配置参数,然后设置一个合理的默认值。

原则25:总是要为配置设置一个合理的默认值。

原则26:设计不良的配置会造成一些困扰。应该总是为配置提供一些示例值。

原则27:配置值必须是用户能够理解和直接填写的。比如:不能让用户填写最大缓存条目的数量,而是应该让用户填写可被用于缓存的最大内存。

原则28:如果输入了未知的配置要抛出错误。永远不要悄悄的忽略。悄悄的忽略配置错误往往是找bug花了数小时的罪魁祸首。

艰难的问题

原则29:梦想着新的编程语言就会变得简单和明了,但往往要想真正掌握会很难。不要轻易的去换编程语言。

(小编点评:“技术极客”是听不进去的,不如把“个人修炼”和“项目采用”分开看待…)

原则30:复杂的拖拉拽的界面是艰难的,不要去尝试这样的效果,除非你准备好了10人年的团队。

(小编点评:我一直不太相信整体性的代码生成,比如MDA,或者拖拉拽建模代替写代码…如果说有成功的,或者是在比较狭小的领域)

最后,说一个我的感受。在一个理想的世界里,一个平台应该是有多个正交组件组成-每个组件都负责一个方面(比如,security,messaging,registry,mdidation,analytics)。好像一个系统构建成这样才是完美的。但不幸的是,现实中我们很难达到这样的状态。因为在项目初始状态时,很多事情是不确定的,你无法做到这样的独立性,现在我更倾向于在开始的时候适当的重复是必要的,当你尝试铲除他们的时候,你会发现引入了新的复杂性,分布本身就意味着复杂。有时候治愈的过程要比疾病本身更加的糟糕。

(小编点评:不同阶段采用不同的做法,照抄往往会东施效颦)

总结

作为一个架构师,应该像园丁一般,更多的是修剪花草,除草而不是去定义和构建,你应该策划而不是指挥,你应该去修剪而不是去定义,应该是讨论而不是贴标签。虽然在短期内可能会觉得也没什么,但从长远看,指导团队找到自己的方式会带来好处。如果你稍不留神,就很容易让架构成为一个空洞的词汇。比如设计者会说他的架构是错误的,但不知道为什么是错误的。一个避免这种情况的好办法就是有一个原则列表,这个原则列表是被广泛接受的,这个列表是人们讨论问题的锚点,也是新手架构师学习的路径。

本文转载自 ImportSource

Image placeholder
IT头条
未设置
  20人点赞

没有讨论,发表一下自己的看法吧

推荐文章
​中台战略:业务中台的8个设计原则

业务中台是一个充满生命力的个体,它承载业务逻辑、沉淀业务数据、产生业务价值,并随着业务不断发展进化。它的设计遵循如下图所示的8个原则。业务中台设计的8大原则01 服务松耦合原则(1)面向接口实现这是服

Kafka 优秀的架构设计!它的高性能是如何保证的?

应大部分的小伙伴的要求,今天这篇咱们用大白话带你认识Kafka。Kafka 基础消息系统的作用大部分小伙伴应该都清楚,这里用机油装箱举个例子:所以消息系统就是如上图我们所说的仓库,能在中间过程作为缓存

从 GFS 失败的架构设计来看一致性的重要性

作者简介陈东明,饿了么北京技术中心架构组负责人,负责饿了么的产品线架构设计以及饿了么基础架构研发工作。曾任百度架构师,负责百度即时通讯产品的架构设计。具有丰富的大规模系统构建和基础架构的研发经验,善于

数字转型 架构演进 2019中国系统架构师大会盛大召开

2019年10月31日~11月2日,由IT168旗下ChinaUnix社区主办的第十一届中国系统架构师大会(SACC2019)在北京隆重召开。自2009年举办以来,大会云集了国内CTO、研发总监、高级

阿里支付宝架构师:谈谈我眼中的高并发架构【好文】

来源:my.oschina.net/u/3772106/blog/1793561前言高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等。为了让业务可以流畅的运行并且

架构师眼中的高并发架构

前言高并发经常发生在有大活跃用户量和用户高聚集的业务场景中,如:秒杀活动、定时领取红包等。为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己

深入浅出 Viewport 设计原理

Viewport是HTML5针对移动端开发新增的一个meta属性,它的作用是为同一网页在不同设备的呈现,提供响应式解决方案。这篇文章尝试通过循序渐进的方式,逐层探索Viewport的设计原理,希望能给

S.O.L.I.D: PHP 面向对象设计的五个基准原则

S.O.L.I.D是首个5个面向对象设计(OOD)准则的首字母缩写,这些准则是由RobertC.Martin提出的,他更为人所熟知的名字是UncleBob。 这些准则使得开发出易扩展、可维护的软件变

上市公司招聘 PHP 高级架构师, 负责公司资讯网站

薪资35-40k*14【职位介绍】负责公司资讯平台开发,管理后端小团队岗位职责:负责公司资讯平台开发,管理后端小团队 负责平台开发、测试和维护工作; 岗位要求:计算机专业5年以上PHP开发经验,熟悉m

上市公司招聘 PHP 高级架构师 (负责人)

薪资35-40k*14【职位介绍】负责公司资讯平台开发,管理后端小团队岗位职责:负责公司资讯平台开发,管理后端小团队 负责平台开发、测试和维护工作; 岗位要求:计算机专业5年以上PHP开发经验,熟悉m

架构师眼中的文化:试用期才是真正的考察时间

如果说架构师在技术上的沉淀称为“武”,那么对于文化的感知和影响、对于团队的带动和辅导、以及多角色沟通等可以称为“文”,文武兼备,才是好架构!管理风格团队是由个体组成的,管理风格往往能够显示出团队文化。

「模仿」是架构师的基本能力:守破离

本文作者曲健,1024生人,天选程序员,浆糊人送外号“大爷DàYé”,目前在奥琪科技担任首席架构师一职。二零一八留不住,朱颜辞镜花辞树。鄙人平素喜偶厌奇,以致现在对2019仍避之不及、兴致索然,更羞愧

阿里巴巴架构师:十问业务中台和我的答案

Photo@  ZachLucero文 |王思轩一切业务数据化,一切数据业务化。“中台”概念这几年非常火,特别是阿里、腾讯、百度、京东等互联网公司最近频繁的基于中台调整组织架构,把“中台”的热度又上升

为什么大部分人做不了架构师?这2点是关键

阿里妹导读:选择有时候比努力重要,真正厉害的人不仅仅是埋头苦干,而是会利用好的思维方式、好的方法,看穿事物的本质,顺势而为,找到事情的最优解,并懂得举一反三。架构师是程序员的目标之一,但大多数程序员无

程序员,练就哪些技能才胜任架构师?

关注「 IT老兵哥 」,赋能程序人生!本系列前序文章索引: 程序员为什么必须要懂架构? 架构到底是什么,你知道吗? 架构都有哪些,我该怎么选? 架构师都干什么,你知道吗? 架构师,我们程序员打怪升级的

相见恨晚,一个架构师也不会用的Lombok注解

课程推荐:Linux开发工程师--学习猿地精品课程 我见过很多反对Lombok的同学,背地里又偷偷的把插件添加了进去,这是真香原理在搞鬼。嘴上说不要,身体很诚实。反对的人,应该是没见过一些业务代码的冗

万字详解Oracle架构、原理、进程,学会世间再无复杂架构

学习是一个循序渐进的过程,从面到点、从宏观到微观,逐步渗透,各个击破,对于Oracle, 怎么样从宏观上来理解呢?先来看一个图,这个图取自于教材,这个图对于从整体上理解ORACLE 的体系结构组件,非

架构转型先行——金融业务场景下的新一代架构实践

  赵勇中国农业银行研发中心架构管理办公室主任工程师中国农业银行研发中心架构管理办公室主任工程师,十年以上金融行业信息化架构设计与管控经验。历经互联网金融、两地三中心、分布式核心银行等大型银行系统工程

SOA架构和微服务架构的区别是什么?

来源:rrd.me/fqdANSOA架构和微服务架构的区别首先SOA和微服务架构一个层面的东西,而对于ESB和微服务网关是一个层面的东西,一个谈到是架构风格和方法,一个谈的是实现工具或组件。1.SOA

施密特:谷歌的五大原则

大数据文摘出品作者:施密特在2013年的《致股东的公开信》中,谷歌创始人拉里·佩奇表示:“随着时间的推移,很多公司都习惯重复自己一贯的做法,只做出很少的渐进式的改变。假以时日,这样的渐进主义会导致落伍

敏捷开发流程之Scrum:3个角色、5个会议、12原则

本文主要从Scrum的定义和目的、敏捷宣言、Scrum中的人员角色、Scrum开发流程、敏捷的12原则等几方面帮助大家理解Scrum敏捷开发的全过程。一、Scrum的定义和目的Scrum是一个用于开发

java-forkjoin框架使用和一些原则

先扯一波使用两个demo解决使用RecursiveAction无状态任务拆分(无返回值状态)注意几个点 awaitQuiescence是监控这个forkjoin是否都完成 awaitTerminati

盗版12306骗3000万人下载,暴利高仿App是如何花式捞钱的?

眼看着春运一天一天临近,我按捺不住激动的心情,准备加入抢票大军。可是,当我在应用商城搜索12306时,却发现一大批“12306”。这些App下载量从几万到几千万(未标“官方版”的累计下载量超一千万),

软件架构被高估,清晰简单的设计被低估

软件架构最佳实践、企业架构模式以及系统描述的正式方法都是非常重要且实用的工具,总会有合适的场景让它们发挥作用。但在设计系统时,请从简单始、以简单终,尽可能避免一切会无谓提高复杂度的架构与正式工具。

Laravel 使用 CURD 之外- Domain,大中型 Laravel 项目架构设计

0x01面向领域的Laravel 人类分类思考,我们的代码应该映射这一点 首先说明,我没有提出这个术语『领域』-我从流行的开发模式DDD中学来的。引用牛津词典,『领域』可以描述为『一个特定范围的活