园区门户网站建设方案,著名网站用什么语言做后台,西安网站建设行业,阜阳讯拓网站建设公司阿里妹导读#xff1a;什么是架构#xff1f;关于架构这个概念很难给出一个明确的定义#xff0c;也没有一个标准的定义。如果#xff0c;硬是要给一个概述#xff0c;阿里巴巴高级技术专家张建飞认为架构就是对系统中的实体以及实体之间的关系所进行的抽象描述。今天什么是架构关于架构这个概念很难给出一个明确的定义也没有一个标准的定义。如果硬是要给一个概述阿里巴巴高级技术专家张建飞认为架构就是对系统中的实体以及实体之间的关系所进行的抽象描述。今天张建飞来谈谈应用架构的核心使命是什么是否与你想得一样往下看一起寻找答案。
架构
架构始于建筑是因为人类发展原始人自给自足住在树上也就不需要架构分工协作的需要将目标系统按某个原则进行切分切分的原则是要便于不同的角色进行并行工作。
为什么需要架构
有系统的地方就需要架构大到航空飞机小到一个电商系统里面的一个功能组件都需要设计和架构。
我很喜欢《系统架构复杂系统的产品设计与开发》里面的一句话结构良好的创造活动要优于毫无结构的创造活动。
与之相对应的现在很多敏捷思想提倡no design只要work就好。期待好的架构可以在迭代中自然涌现。这个想法有点太理想化了在现实中只要能work的代码工程师是很少有动力去重构和优化的。
架构师的职责
作为架构师我们最重要的价值应该是“化繁为简”。但凡让事情变得更复杂让系统变得更晦涩难懂的架构都是值得商榷的。
架构师的工作就是要努力训练自己的思维用它去理解复杂的系统通过合理的分解和抽象使哪些系统不再那么难懂。我们应该努力构建易懂的架构使得在系统上工作的其他人员例如设计者、实现者、操作员等可以较为容易地理解这个系统。
软件架构
软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段这些抽象组件被细化为实际的组件比如具体某个类或者对象。在面向对象领域中组件之间的连接通常用接口来实现。
软件架构为软件系统提供了一个结构、行为和属性的高级抽象由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系而且指定了整个软件系统的组织和拓扑结构提供了一些设计决策的基本原理。
软件架构的核心价值应该只围绕一个核心命题控制复杂性。他并不意味着某个特定的分层结构某个特定的方法论贫血、DDD等。
软件架构分类
在介绍应用架构之前我们先来看一下软件架构的分类。
随着互联网的发展现在的系统要支撑数亿人同时在线购物、通信、娱乐的需要相应的软件体系结构也变得越来越复杂。软件架构的含义也变得更加宽泛我们不能简单地用一个软件架构来指代所有的软件架构工作。按照我个人理解我将软件架构划分为 业务架构由业务架构师负责也可以称为业务领域专家、行业专家。业务架构属于顶层设计其对业务的定义和划分会影响组织结构和技术架构。例如阿里巴巴在没有中台部门之前每个业务部门的技术架构都是烟囱式的淘宝、天猫、飞猪、1688等各有一套体系结构。而后成立了共享平台事业部打通了账号、商品、订单等体系让商业基础实施的复用成为可能。
应用架构由应用架构师负责他需要根据业务场景的需要设计应用的层次结构制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平从而在快速的支撑业务发展的同时在保证系统的可用性和可维护性的同时确保应用满足非功能属性要求性能、安全、稳定性等。
分布式系统架构分布式系统基本是稍具规模业务的必选项。它需要解决服务器负载分布式服务的注册和发现消息系统缓存系统分布式数据库等问题同时架构师要在CAPConsistencyAvailabilityPartition tolerance之间进行权衡。
数据架构对于规模大一些的公司数据治理是一个很重要的课题。如何对数据收集、数据处理提供统一的服务和标准是数据架构需要关注的问题。其目的就是统一数据定义规范标准化数据表达形成有效易维护的数据资产搭建统一的大数据处理平台形成数据使用闭环。
物理架构物理架构关注软件元件是如何放到硬件上的包括机房搭建、网络拓扑结构网络分流器、代理服务器、Web服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。
运维架构负责运维系统的规划、选型、部署上线建立规范化的运维体系。
典型应用架构
分层架构
分层是一种常见的根据系统中的角色职责拆分和组织代码单元的常规实践。常见的分层结构如下图所示 CQRS
CQS(Command Query Separation命令查询分离)最早来自于Betrand MeyerEiffel语言之父OCP提出者提出的概念。其基本思想在于任何一个对象的方法可以分为两大类
命令(Command)不返回任何结果(void)但会改变对象的状态。查询(Query)返回结果但是不会改变对象的状态对系统没有副作用。六边形架构
六边形架构是Alistair Cockburn在2005年提出解决了传统的分层架构所带来的问题实际上它也是一种分层架构只不过不是上下而是变成了内部和外部如下图所示。 六边形架构又称为端口-适配器架构这个名字更容器理解。六边形架构将系统分为内部内部六边形和外部内部代表了应用的业务逻辑外部代表应用的驱动逻辑、基础设施或其他应用。
适配器分为两种类型如下图所示左侧代表 UI 的适配器被称为主动适配器Driving Adapters因为是它们发起了对应用的一些操作。而右侧表示和后端工具链接的适配器被称为被动适配器Driven Adapters因为它们只会对主适配器的操作作出响应。 洋葱圈架构
洋葱架构与六边形架构有着相同的思路它们都通过编写适配器代码将应用核心从对基础设施的关注中解放出来避免基础设施代码渗透到应用核心之中。这样应用使用的工具和传达机制都可以轻松地替换可以一定程度地避免技术、工具或者供应商锁定。 不同的是洋葱架构还告诉我们企业应用中存在着不止两个层次它在业务逻辑中加入了一些在领域驱动设计的过程中被识别出来的层次ApplicationDomain ServiceDomain modelInfrastructure等。
另外它还有着脱离真实基础设施和传达机制应用仍然可以运行的便利这样可以使用 mock 代替它们方便测试。 在洋葱架构中明确规定了依赖的方向
外层依赖内层内层对外层无感知。
COLA应用架构
COLA架构是我团队自主研发的应用架构目前已经开源。在COLA的设计中我们充分汲取了经典架构的优秀思想。除此之外我们补充了规范设计和扩展设计并且使用Archetype的方式将架构固化下来以便可以快速的在开发中使用。
开源地址
COLA架构目前已经开源地址 https://github.com/alibaba/COLA
分层设计
COLA的分层是一种改良了的三层架构。主要是将传统的业务逻辑层拆分成应用层、领域层和基础实施层。如下图所示左边是传统的分层架构右边是COLA的分层架构。 其每一层的作用范围和含义如下
1展现层Presentation Layer负责以Rest的格式接受Web请求然后将请求路由给Application层执行并返回视图模型View Model其载体通常是DTOData Transfer Object
2应用层Application Layer主要负责获取输入组装上下文做输入校验调用领域层做业务处理如果需要的话发送消息通知。当然层次是开放的若有需要应用层也可以直接访问基础实施层
3领域层Domain Layer主要是封装了核心业务逻辑并通过领域服务Domain Service和领域对象Entities的函数对外部提供业务逻辑的计算和处理
4基础实施层Infrastructure Layer主要包含Tunnel数据通道、Config和Common。这里我们使用Tunnel这个概念来对所有的数据来源进行抽象这些数据来源可以是数据库MySQLNoSql、搜索引擎、文件系统、也可以是SOA服务等Config负责应用的配置Common是通用的工具类。
扩展设计
对于只有一个业务的简单场景对扩展性的要求并不突出这也是为什么扩展设计常被忽略的原因因为我们大部分的系统都是从单一业务开始的。但是随着业务场景越来越复杂代码里面开始出现大量的if-else逻辑。此时除了常规的策略模式以外我们可以考虑在架构层面提供统一的扩展解决方案。
在扩展设计中我们提炼出两个重要的概念一个是业务身份另一个是扩展点。
业务身份是指业务在系统唯一标识一个业务或者一个场景的标志。在具体实现中我们使用BizCode来表示业务身份其中BizCode采用类似Java包名命名空间的方式。例如我们可以用“ali.tmall”表示阿里天猫业务用“ali.tmall.car” 表示阿里天猫的汽车业务而用ali.tmall.car.aftermarket代表这是阿里天猫的汽车业务的后市场场景。
每个业务或者场景都可以实现一个或多个扩展点ExtensionPoint也就是说一个业务身份加上一个扩展点可以唯一地确定一个扩展实现Extension。而这个业务身份和扩展点的组合我们将其称之为扩展坐标ExtensionCoordinate如下图所示。 这样通过业务身份扩展点我们就可以从框架层面实现对不同租户不同业务不同场景的扩展定制了。整个阿里业务中台正是基于这个思想实现的多业务支撑的。
规范设计
任何事物都是规则性和随机性的组合。规范的意义就在于我们可以将规则性的东西固化下来尽量减少随心所欲带来的复杂度一致性可以降低系统复杂度。从命名到架构皆是如此而架构本身就是一种规范和约束破坏这个约束也就破坏了架构。
COLA制定了一些列的规范包括组件Module结构、包Package结构、命名等。
比如对于组件我们要求使用COLA的应用都应该遵循如下图所示的组件划分 COLA架构总览
在架构思想上COLA主张像六边形架构那样使用端口-适配器去解耦技术细节主张像洋葱圈架构那样以领域为核心并通过依赖倒置反转领域层的依赖方向。最终形成如下图所示的组件关系。 换一个视角从COLA应用处理响应一个请求的过程来看。COLA使用了CQRS来分离命令和查询的职责使用扩展点和元数据来提升应用的扩展性。整个处理流程如下图所示 应用架构的核心
纵观上面介绍的所有应用架构我们可以发现一个共同点就是“核心业务逻辑和技术细节分离”。 是的六边形架构、洋葱圈架构、以及COLA架构的核心职责就是要做核心业务逻辑和技术细节的分离和解耦。
试想一下业务逻辑和技术细节糅杂在一起的情况所有的代码都写在ServiceImpl里面前几行代码是做validation的事接下来几行是做convert的事然后是几行业务处理逻辑的代码穿插着我们需要通过RPC或者DAO获取更多的数据拿到数据后又是几行convert的代码在接上一段业务逻辑代码然后还要落库发消息.....等等。
再简单的业务按照上面这种写代码的方式都会变得复杂难维护。
因此我认为应用架构的核心使命就是要分离业务逻辑和技术细节。让核心业务逻辑可以反映领域模型和领域应用可以复用可以很容易被看懂。让技术细节在辅助实现业务功能的同时可以被替换。
最后我们发现应用架构的道就是“让上帝的归上帝凯撒的归凯撒。”
原文链接 本文为云栖社区原创内容未经允许不得转载。
