您的位置:首页 > 运维架构 > Apache

Apache 的架构师们遵循的 30 条设计原则&软件架构的10个常见模式

2020-05-11 04:06 686 查看

架构之道:如何设计出灵活、高可用性以及能够快速适应变化的系统架构?

什么是道,什么是术?道是事物发展的本质规律,术是事物发展的具体途径。规律只有一个,途径很多,条条大路通罗马,罗马是道,大路是术。道为本,术为途,如果事先知道罗马在哪里,那么遍地是路,路路相通。架构也是如此,如果能领悟架构的本质,就不会拘泥于现有的实践和理论框框,而以最直接的方式解决问题,无招胜有招。本文的内容包括架构的本质、架构的服务对象、架构师能力模型 、架构境界等。

架构的本质

任何系统,自然情况下,都是从有序到无序,这是有科学依据的, 按照热力学第二定律,自然界的一切自发过程都有方向性,一个孤立系统会由有序变为无序,即它的熵会不断增加,最终寂灭。但生物可以通过和外界交互,主动进行新陈代谢,制造 “负熵” 来保证自身有序,继续生存。

同样,一个软件系统随着功能越来越多,调用量急剧增长,整个系统逐渐碎片化,越来越无序,最终无法维护和扩展,所以系统在一段时间的野蛮生长后,也需要及时干预,避免越来越无序。

架构的本质就是对系统进行有序化重构,不断减少系统的 “熵”,使系统不断进化。

那架构是如何实现无序到有序的呢?基本的手段就是分和合,先把系统打散,然后重新组合。

在首席架构师眼里,架构的本质是……分的过程是把系统拆分为各个子系统 / 模块 / 组件,拆的时候,首先要解决每个组件的定位问题,然后才能划分彼此的边界,实现合理的拆分。合就是根据最终要求,把各个分离的组件有机整合在一起,相对来说,第一步的拆分更难。

拆分的结果使开发人员能够做到业务聚焦、技能聚焦,实现开发敏捷,合的结果是系统变得柔性,可以因需而变,实现业务敏捷。

架构师的能力要求包括:

兼具技术的广度(多领域知识)和深度(技术前瞻)

兼具思维的高度(抽象思维)和深度(问题到本质)

兼具感性(沟通)和理性(平衡)

架构师的境界

架构师从境界上由浅到深可以分为四层:第一看山不是山,第二看山是山,第三看山不是山,第四看山是山。

在首席架构师眼里,架构的本质是……刚接手项目时,对业务不了解,时时被业务方冒出的术语弄得一愣一愣的,如果把现有问题比作山,则是横看成岭侧成峰,根本摸不透,此时看山不是山。

经过业务梳理和对系统深入了解,可以设计出一个屌丝的方案,把各个系统串起来,解决当前的问题,对当前这个山能够看清楚全貌,此时能够做到看山是山。

通过进一步抽象,发现问题的本质,原来这个问题是共性的,后续还会有很多类似问题。设计上进行总结和升华,得出一个通用的方案,不光能解决当前的问题,还可以解决潜在的问题。此时看到的已经是问题本质,看山不是山。

最后回到问题本身,去除过度的抽象,给出的设计简洁明了,增之一分嫌肥,减之一分嫌瘦,既解决当前问题,又保留最基本的扩展,此时问题还是那个问题,山还是那个山。

第一境界给不出合适方案,不表。

第二境界的方案只解决表面问题,往往设计不够,碰到其它类似问题或者问题稍微变形,系统需要重新做。

第三境界的方案往往过度设计,太追求通用化会创造出过多抽象,生造概念,理解和实现均困难,此时系统的无序度反而增加,过犹不及。

第四境界的方案,在了解问题本质的基础上,同时考虑现状,评估未来,不多做,不少做。

佛教讲空和色,色即事物现象,空即事物本质,从这个意义上说,第一重境界无色无空,第二重境界过色,第三重境界过空,第四重境界站在色和空之间,既色又空,不执着于当前,不虚无于未来。

不空不色,既空既色,道法自然,本性如来,架构之髓也。

软件架构介绍

架构定义:

软件架构不仅仅注重软件本身的结构和行为, 还注重其他特性:使用, 功能性, 性能, 弹性, 重用, 可理解性, 经济和技术的限制及权衡。

软件架构的目标:

可延伸性(Extensible)。在新技术出现的时候,一个软件系统应当允许导入新技术,从而对现有系统进行功能和性能的扩展;

可维护性(Maintainable)。软件系统的维护包括两方面:

1、排除现有的错误;

2、将新的软件需求反映到现有系统中去,一个易于维护的系统可以有效地降低技术支持的花费。

客户体验(Customer Experience)。软件系统必须易于使用。

市场时机(Time to Market)。软件用户

软件逻辑架构:

逻辑架构:软件系统中元件之间的关系,比如用户界面,数据库,外部系统接口,商业逻辑元件,等等

软件物理架构:

物理架构:软件元件是怎样放到硬件上的?

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

基本原则

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

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

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

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

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

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

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

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

功能选择

原则 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 事务是无法扩展的。

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

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

用户体验

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

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

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

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

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

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

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

艰难的问题

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

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

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

总结

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

软件架构的10个常见模式

企业规模的软件系统该如何设计呢?在开始写代码之前,我们需要选择一个合适的架构,这个架构将决定软件实施过程中的功能属性和质量属性。因此,了解软件设计中的不同架构模式对我们的软件设计会有较大的帮助。

什么是架构模式?根据维基百科:架构模式是针对特定软件架构场景常见问题的通用、可重用解决方案。架构模式类似于软件设计模式,但范围更广。本文将简要解释10种常见架构模式及其用法、优缺点。

  • 分层模式(Layered pattern)

  • 客户端-服务器模式(Client-server pattern)

  • 主从模式(Master-slave pattern)

  • 管道-过滤器模式(Pipe-filter pattern)

  • 代理模式(Broker pattern)

  • 点对点模式(Peer-to-peer pattern)

  • 事件-总线模式(Event-bus pattern)

  • 模型-视图-控制器模式(Model-view-controller pattern)

  • 黑板模式(Blackboard pattern)

  • 解释器模式(Interpreter pattern)

1. 分层模式

此模式用于可分解为子任务的结构化程序,每个子任务都位于特定的抽象层级,每一层都为上一层提供服务。一般信息系统最常见的4个层次如下。

  • 表示层(也称为UI层)

  • 应用层(也称为服务层)

  • 业务逻辑层(也称为领域层)

  • 数据访问层(也称为持久层)

应用场景:

  • 一般的桌面应用程序

  • 电子商务web应用程序

  • 一般的移动App

2. 客户端-服务器模式

这种模式由两部分组成:服务器和多个客户端。服务器将向多个客户端提供服务。客户端从服务器请求服务,服务器向这些客户端提供相关服务。此外,服务器继续侦听客户端请求。

应用场景:

  • 电子邮件、文档共享和银行等在线应用程序。

  • 基于IPC的应用程序

3.主从模式

这种模式由两部分组成:主节点和从节点。主节点将工作分配给相同的从节点,并根据从节点返回的结果计算最终结果。

应用场景:

  • 在数据库复制中,主数据库被视为权威源数据库,从数据库与之同步。

  • 通过总线连接到计算机系统(主驱动器和从驱动器)的外围设备。

  • 进程内的多线程应用。

4.管道-过滤器模式

这种模式可用于构造生成和处理数据流的系统。每个处理步骤都包含一个过滤器组件。要处理的数据通过管道传递。这些管道可用于缓冲或同步目的。

应用场景:

  • 编译器。连续过滤器执行词法分析、词法解析、语义分析和代码生成。

  • 生物信息学的工作流

  • 工具链式的应用程序

5. 代理模式

这种模式通过解耦组件来构造分布式系统。这些组件可以通过远程服务调用彼此交互。代理组件负责协调组件之间的通信。服务器向代理发布功能(服务和特征)。客户端向代理请求服务,然后代理将客户端重定向到合适的服务。需要注意broker,agent,proxy以及delegate的区别。

应用场景:

  • 消息代理软件,例如:Apache ActiveMQ、Apache Kafka、RabbitMQ和JBoss消息传递。

  • 网络传输中的代理软件。

6. P2P模式

在这种模式中,每个组件都称为对等节点。对等节点既可以作为客户机(从其他对等节点请求服务),也可以作为服务器(向其他对等节点提供服务)。对等节点可以充当单个客户机或服务器,也可以同时充当客户机和服务器,并且可以随着时间变化动态地更改角色。

使用场景:

  • 文件共享网络,例如Gnutella和G2等。

  • 多媒体协议,如P2PTV和PDTP。

7. 事件-总线模式

这种模式也被称为订阅发布模式,主要处理事件,有4个主要组件:事件源、事件监听者、通道和事件总线。事件源将消息发布到事件总线上的特定通道,监听者订阅特定的通道。消息发布到监听者之前订阅的通道,监听者将收到消息的通知。

使用场景:

  • 安卓开发

  • 通知服务

  • 注册中心

8. 模型-视图-控制器模式

这种模式,也称为MVC模式,将一个交互应用程序分为三个部分:

  • 模型-包含核心功能和数据

  • 视图——向用户显示信息(可以定义多个视图)

  • 控制器——处理来自用户的输入

这样做是为了将信息的内部表示、信息呈现给用户的方式、接受用户输入的方式分离开来。这种模式解耦组件并允许有效的代码重用。

应用场景:

  • 一般的web应用程序架构

  • Django和Rails等Web框架

  • 一般的GUI 应用程序

9. 黑板模式

这种模式对于没有确定解决方案策略的问题非常有用。黑板图案由三个主要部分组成:

  • 黑板:一个结构化的全局内存,包含来自解决方案空间的对象

  • 知识源:具有自己表示形式的专门化模块

  • 控制组件:选择、配置和执行模块

所有的组件都可以到达黑板。组件可以生成添加到黑板上的新数据对象。组件在黑板上查找特定类型的数据,并通过与现有的知识源进行模式匹配找到这些数据。

应用场景:

  • 语音识别

  • 车辆识别及追踪

  • 蛋白质结构识别

  • 声纳信号的解释

10. 解释器模式

这种模式用于设计一个解释专用语言编写的程序组件。它主要指定如何评估每一行程序,即用特定语言编写的句子或表达式。其基本思想是语言的每个符号都有一个类。

应用场景:

  • 数据库查询语言,如SQL。

  • 用于描述通信协议的语言。

下面的表格总结了每种架构模式的优缺点。

Kotlin开发者社区

专注分享 Java、 Kotlin、Spring/Spring Boot、MySQL、redis、neo4j、NoSQL、Android、JavaScript、React、Node、函数式编程、编程思想、"高可用,高性能,高实时"大型分布式系统架构设计主题。

东海陈光剑 博客专家 原创文章 1741获赞 1165访问量 82万+ 关注 他的留言板
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: