架构设计
在架构设计过程中,我们会根据需要做出不同的架构设计,而在设计时需要涉及一定的架构设计核心要素。
架构设计概要
架构设计是从业务需求到系统实现的一个转换,是对需求进一步深入分析的过程,用于确定系统中实体与实体的关系,以及实体的形式与功能。架构可根据从业务需求到系统实现的不同需要分为:业务架构、应用架构、数据架构、技术架构。下面以电商系统为例进行架构设计。
业务架构
业务架构是对业务需求的提炼和抽象,使用一套方法论对产品(项目)所涉及需求的业务进行业务边界划分,简单地讲就是根据一套逻辑思路进行业务的拆分,开发软件必须满足业务需求,否则就是空中楼阁。软件系统在业务上的复杂度问题,可以从业务架构的角度切分工作交界面来解决。比如在做一个电商网站时,需要将商品类目、商品、订单、支付、退款等功能很清晰地划分出来,不要在业务架构中考虑用什么技术开发、并发量是否太大、选择什么样的硬件,等等。
这里简单规划了电商系统的业务模块,对其根据业务架构的模块不断细化,一直分解到代码流程。对于软件开发而言,以业务架构为依托,架构师和开发者能比较清晰地看到系统的业务全貌,架构师能更方便地分析系统复杂度,分解业务逻辑,做好开发的分工,如图5.1所示。
图5.1
业务架构是决定一个软件项目能否顺利开展的总纲,软件架构是业务架构在技术层面的映射,合理的开发分工也应该基于业务架构去做。如果没有业务架构,进行软件开发就会很盲目。业务架构是需求和开发的汇聚点,需求分析是否做到位,功能开发是否达到预期目标,都以此为依托。我们在工作中会遇到一些问题,例如研发人员说需求分析做得不到位,而做需求的人员会质疑需求做到怎样才算到位,为什么开发出的产品和用户想要的不一致,这些从根上来说,都是因为没有将业务架构梳理清楚,没有达成共识。
站在软件项目的角度来看,在项目前期做好业务架构设计,对整个项目的开发都有重要的意义。例如,对于比较类似的业务系统,可能业务架构在比较粗的颗粒度上是一样的,而在细化过程中不一样。
在做项目时,当手头有一个现成的系统,需要做一个需求类似的项目时,大家可能会首先尝试用现成的系统去覆盖新项目,以求利益最大化。对于该想法能否实现,可以通过业务架构来衡量,如果没有业务架构,则接下来的工作会非常盲目。业务架构的设计原则如下。
(1)将业务平台化。
◎ 业务平台化,相互独立,例如交易平台、物流平台、支付平台、广告平台等。
◎ 基础业务下沉,可复用,例如用户、商品、类目、促销、时效等。(2)将核心业务和非核心业务分离。将电商系统的核心业务和非核心业务如主交易服务和通用交易服务分离,将核心业务精简(利于稳定),并将非核心业务多样化。
(3)隔离不同类型的业务。
◎ 交易平台的作用是让买家和卖家签订交易合同,所以需要优先保证高可用,让用户能快速下单。
◎ 履约业务对可用性没有太高要求,但要优先保证一致性。
◎ 秒杀业务对高并发要求很高,应该和常规业务分离。
(4)区分主流程和辅助流程。要清楚哪些是电商系统的主流程,在运行时优先保证主流程的顺利完成;对辅助流程可以采用后台异步的方式,避免辅助流程的失败影响主流程的失败回流。
应用架构
应用架构介于业务与技术之间,是对整个系统实现的总体架构,需要指出系统的层次、系统开发的原则、系统各个层次的应用服务。
如图5.2所示为将系统分为表现层、业务流程层、服务层、服务构建层、数据层、集成层、数据架构层和服务治理层,并写明每个层次的应用提供的服务。
在进行系统拆分时,要平衡业务和技术的复杂度,保证系统形散神不散。系统采用什么样的应用架构,则受到业务复杂度的影响,包括企业的发展阶段和业务特点;同时受技术复杂度的影响,包括 IT技术的发展阶段和内部技术人员的水平。业务的复杂度(包括业务量大)必然带来技术的复杂度,应用架构的目标是在解决业务复杂度的同时避免技术太复杂,确保业务架构落地。
图5.2