作为首席架构师,我是如何选择并落地架构方案的?

2018-05-21 17:30 来源:网络整理
如何针对当前需求,选择合适的应用架构,如何面向未来,保证架构平滑过渡,这个是软件开发者,特别是架构师,

无架构,不系统,架构是大型系统的关键。从形上看,架构是系统的骨架,支撑和链接各个部分;从神上看,架构是系统的灵魂,深刻体现业务本质。

架构可细分为业务架构、应用架构、技术架构,业务架构是战略,应用架构是战术,技术架构是装备。其中应用架构承上启下,一方面承接业务架构的落地,另一方面影响技术选型。

如何针对当前需求,选择合适的应用架构,如何面向未来,保证架构平滑过渡,这个是软件开发者,特别是架构师,都需要深入思考的问题。本文基于作者在大型互联网系统的实践和思考,和大家一起探讨应用架构的选型。

相关厂商内容

罗辑思维Go语言微服务改造完整过程 阿里菜鸟全球跨域RPC架构实践痛点难点 从UC内核角度谈谈PWA技术在阿里体系的实践及影响 没有数据和算法基础,如何快速晋升人工智能全能大神? 滴滴地图引擎架构实践和AI技术应用

相关赞助商

本文主要内容包括:

应用架构本质

单体式

分布式

SOA架构

SOA落地方式

应用架构进化

应用架构本质

应用作为独立可部署的单元,为系统划分了明确的边界,深刻影响系统功能组织、代码开发、部署和运维等各方面,应用架构定义系统有哪些应用、以及应用之间如何分工和合作。

分有两种方式,一种是水平分,按照功能处理顺序划分应用,比如把系统分为web前端/中间服务/后台任务,这是面向业务深度的划分。另一种是垂直分,按照不同的业务类型划分应用,比如进销存系统可以划分为三个独立的应用,这是面向业务广度的划分。

应用的反映应用之间如何协作,共同完成复杂的业务case,主要体现在应用之间的通讯机制和数据格式,通讯机制可以是同步调用/异步消息/共享DB访问等,数据格式可以是文本/XML/JSON/二进制等。

应用的偏向于业务,反映业务架构,应用的合偏向于技术,影响技术架构。分降低了业务复杂度,系统更有序,合增加了技术复杂度,系统更无序。

应用架构的本质是通过系统拆分,平衡业务和技术复杂性,保证系统形散神不散

系统采用什么样的应用架构,受业务复杂性影响,包括企业发展阶段和业务特点;同时受技术复杂性影响,包括IT技术发展阶段和内部技术人员水平。业务复杂性(包括业务量大)必然带来技术复杂性,应用架构目标是解决业务复杂性的同时,避免技术太复杂,确保业务架构落地。

常见的应用架构有多种,下面根据系统拆分方式,以及如何平衡业务与技术的角度进行分析,讨论各自的适用性,给企业应用架构选型提供参考。

单体式应用 1、架构模型

系统只有一个应用,相应地,代码放在一个工程里管理;打包成一个应用;部署在一台机器;在一个DB里存储数据。单体式应用的架构如下图所示:

单体式应用采用分层架构,按照调用顺序,从上到下一般为表示层、业务层、数据访问层、DB层,表示层负责用户体验,业务层负责业务逻辑,数据访问层负责DB层的数据存取。

单体应用在水平方向上,上下层之间职责划分清晰;但垂直方向上缺乏清晰的边界,上下层模块之间是多对多的依赖关系,比如业务模块1 (图中BO1)可能调用数据层所有模块DAO 1~3, DAO1也可能被业务层所有模块BO1~3调用。

单体应用通过水平分层,降低了业务复杂性;同时模块之间是进程内部调用,技术实现简单。

但单体应用对系统的切分不彻底,只有水平切分,并且是逻辑上,因此适合业务比较单一,但深度上比较复杂的系统,比如TCP/IP网络通讯,从应用层/传输层/网络层/链路层,层层推进,类似这样的系统可以方便地增加水平层次去适配。

对于广度上复杂的业务,由于缺乏垂直切分,强行把不同业务绑定在一起,整个系统神散形不散,带来一系列问题。比如OTA网站包含机票/酒店/旅游等多个垂直业务板块,每块都比较独立,就不适合放在一起开发维护。

2、优缺点

单体式应用的优点和缺点都很鲜明,如下图所示。


上一篇:王福强:一名架构师的自我修养
下一篇:当架构师遇到互联网+:SACC2015带你飞