[关闭]
@qidiandasheng 2022-08-07T13:20:58.000000Z 字数 7047 阅读 74

从零开始学架构(😁)

架构


架构解决的问题

解决复杂度带来的问题,复杂度来源包括:高性能、高可用、可拓展性、(低成本,安全,规模)

高可用

系统无中断地执行其功能的能力,代表系统的可用性程度,是进行系统设计时的准则之一。

可拓展性

正确预测变化、完美封装变化。

预测变化的复杂性在于:

需要设计变化层和稳定层之间的接口:

应对变化的方案是提炼出一个“抽象层”和一个“实现层”。抽象层是稳定的,实现层可以根据具体业务需要定制开发,当加入新的功能时,只需要增加新的实现,无须修改抽象层。这种方案典型的实践就是设计模式和规则引擎。

可用研究一下适配器模式装饰模式

安全

客户端安全主要在于代码混淆、接口加密等

规模

规模带来复杂度的主要原因就是“量变引起质变”,当数量超过一定的阈值后,复杂度会发生质的变化。

随着业务的发展,规模带来的常见复杂度有:

(1)业务功能越来越多,调用逻辑越来越复杂;

(2)数据容量、类型、关联关系越来越多。

规模问题需要与高性能、高可用、高扩展、高伸缩性统一考虑。常采用“分而治之,各个击破”的方法策略。

架构设计三原则

合适原则、简单原则、演化原则

合适原则

合适优于业界领先。

真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的,能够合理地将资源整合在一起并发挥出最大功效,并且能够快速落地。这也是很多 BAT 出来的架构师到了小公司或者创业团队反而做不出成绩的原因,因为没有了大公司的平台、资源、积累,只是生搬硬套大公司的做法,失败的概率非常高。

简单原则

简单原则宣言:“简单优于复杂”。

所以架构设计时如果简单的方案和复杂的方案都可以满足需求,最好选择简单的方案。

演化原则

演化原则宣言:“演化优于一步到位”。

对于建筑来说,永恒是主题;而对于软件来说,变化才是主题。软件架构需要根据业务的发展而不断变化。设计 Windows 和 Android 的人都是顶尖的天才,即便如此,他们也不可能在 1985 年设计出 Windows 8,不可能在 2009 年设计出 Android 6.0。

软件架构设计演化过程:

首先,设计出来的架构要满足当时的业务需要。

其次,架构要不断地在实际应用过程中迭代,保留优秀的设计,修复有缺陷的设计,改正错误的设计,去掉无用的设计,使得架构逐渐完善。

第三,当业务发生变化时,架构要扩展、重构,甚至重写;代码也许会重写,但有价值的经验、教训、逻辑、设计等(类似生物体内的基因)却可以在新架构中延续。

架构设计流程

识别复杂度

设计备选方案

  1. 几种常见的架构设计误区

(1)设计最优秀的方案。不要面向“简历”进行架构设计,而是要根据“合适”、“简单”、“演进”的架构设计原则,决策出与需求、团队、技术能力相匹配的合适方案。

(2)只做一个方案。一个方案容易陷入思考问题片面、自我坚持的认知陷阱。

  1. 备选方案设计的注意事项

(1)备选方案不要过于详细。备选阶段解决的是技术选型问题,而不是技术细节。

(2)备选方案的数量以 3~5个为最佳。

(3)备选方案的技术差异要明显。

(4)备选方案不要只局限于已经熟悉的技术。

评估和选择备选方案

常见的方案质量属性点有:性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性等。

详细方案设计

可拓展架构模式

可扩展性架构的设计方法很多,但万变不离其宗,所有的可扩展性架构设计,背后的基本思想都可以总结为一个字:拆!

常见的拆分思路有如下三种:

流程 > 服务 > 功能

例子

TCP/IP 协议栈:

例子二

学生信息管理系统

不同的拆分方式,将得到不同的系统架构,典型的可扩展系统架构有:

当然我们可以在系统架构设计中进行组合使用:

可拓展架构模式:分层架构和SOA

分层架构设计最核心的一点就是需要保证各层之间的差异足够清晰,边界足够明显,让人看到架构图后就能看懂整个架构,这也是分层不能分太多层的原因。否则如果两个层的差异不明显,就会出现程序员小明认为某个功能应该放在 A 层,而程序员老王却认为同样的功能应该放在 B 层,这样会导致分层混乱。如果这样的架构进入实际开发落地,则 A 层和 B 层就会乱成一锅粥,也就失去了分层的意义。

分层结构的另外一个特点就是层层传递,也就是说一旦分层确定,整个业务流程是按照层进行依次传递的,不能在层之间进行跳跃。好处在于强制将分层依赖限定为两两依赖,降低了整体系统复杂度。

但分层结构的代价就是冗余,也就是说,不管这个业务有多么简单,每层都必须要参与处理,甚至可能每层都写了一个简单的包装函数。以用户管理系统最简单的一个功能“查看头像”为例。查看头像功能的实现很简单,只是显示一张图片而已,但按照分层分册架构来实现,每层都要写一个简单的函数。但如果我直接最上面一层访问最底层的数据层,就可以省却中间的冗余设计。

分层架构的优势就体现在通过分层强制约束两两依赖,一旦自由选择绕过分层,时间一长,架构就会变得混乱。

分层架构另外一个典型的缺点就是性能,因为每一次业务请求都需要穿越所有的架构分层,有一些事情是多余的,多少都会有一些性能的浪费。当然,这里所谓的性能缺点只是理论上的分析,实际上分层带来的性能损失,如果放到 20 世纪 80 年代,可能很明显;但到了现在,硬件和网络的性能有了质的飞越,其实分层模式理论上的这点性能损失,在实际应用中,绝大部分场景下都可以忽略不计。

微服务架构

微服务的架构理念要求“快速交付”,相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。如果没有这些基础能力支撑,微服务规模一旦变大(例如,超过 20 个微服务),整体就难以达到快速交付的要求,这也是很多企业在实行微服务时踩过的一个明显的坑,就是系统拆分为微服务后,部署的成本呈指数上升。

affc409d5f4b05616e944001ebae0ba8.png-20.9kB

微服务的坑:

微服务基础设施

3b4eda0b9786987879a996da1360330e.jpg-134.5kB

客户端是否可以提供这样一层微服务基础设施层框架,比如Spring Cloud 项目,涵盖了服务发现、服务路由、网关、配置中心等功能;

基础设施搭建优先级:

  1. 服务发现、服务路由、服务容错:这是最基本的微服务基础设施。
  2. 接口框架、API 网关:主要是为了提升开发效率,接口框架是提升内部服务的开发效率,API 网关是为了提升与外部服务对接的效率。
  3. 自动化部署、自动化测试、配置中心:主要是为了提升测试和运维效率。
  4. 服务监控、服务跟踪、服务安全:主要是为了进一步提升运维效率。

微内核架构

微内核架构(Microkernel Architecture),也被称为插件化架构(Plug-in Architecture),是一种面向功能进行拆分的可扩展性架构,通常用于实现基于产品的应用。

微内核架构包含两类组件:核心系统(core system)和插件模块(plug-in modules)。核心系统负责和具体业务功能无关的通用功能,例如模块加载、模块间通信等;

微内核的核心系统设计的关键技术有:插件管理、插件连接和插件通信。

OSGi 框架的逻辑架构图:

架构实战

架构师如何判断技术的演进方向

服务类的业务发展路径是这样的:提出一种创新的服务模式→吸引了一批用户→业务开始发展→吸引了更多用户→服务模式不断完善和创新→吸引越来越多的用户,如此循环往复。在这个发展路径中,技术并没有成为业务发展的驱动力,反过来由于用户规模的不断扩展,业务的不断创新和改进,对技术会提出越来越高的要求,因此是业务驱动了技术发展。

除非是开创新的技术能够推动或者创造一种新的业务,其他情况下,都是业务的发展推动了技术的发展。

判断标准

对于架构师来说,判断业务当前和接下来一段时间的主要复杂度是什么就非常关键。判断不准确就会导致投入大量的人力和时间做了对业务没有作用的事情,判断准确就能够做到技术推动业务更加快速发展。那架构师具体应该按照什么标准来判断呢?

基于业务发展阶段进行判断,这也是为什么架构师必须具备业务理解能力的原因。不同的行业业务发展路径、轨迹、模式不一样,架构师必须能够基于行业发展和企业自身情况做出准确判断。

参照他人的架构演进,将自己的架构一步设计到位我觉得这本身就是个伪命题。

架构师如何做?

互联网技术演进模式

互联网业务发展一般分为几个时期:初创期、发展期、竞争期、成熟期。

4b87cf33a27a5f4e1459b3d1544a76cd.png-122.5kB

不同时期的差别主要体现在两个方面:复杂性用户规模

业务复杂性

用户规模

用户量增大对技术的影响主要体现在两个方面:性能要求越来越高、可用性要求越来越高。

APP架构

以手机 App 为例,首先,我们分析一下 App 的复杂度主要来源是什么?通常情况下,App的主要复杂度就是可扩展,因为要不断地开发新的需求;高性能和高可用也涉及,高性能主要和用户体验有关;高可用主要是减少崩溃。其次,再看 App的架构需要遵循架构设计原则么?答案是肯定需要。刚开始为了业务快速开发,可能用“原生 +H5”混合架构;后来业务发展,功能更复杂了,H5 可能难以满足体验,架构又需要演进到“纯原生”;如果业务再发展,规模太庞大,则架构又可能需要演进到“组件化、容器化”。以上通过手机 App 的为例说明这套架构设计理论是通用的,有兴趣的同学可以按照这种方式分析一下企业应用,会发现这套理论也是适应的。

参考

什么才是真正的架构设计?

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注