【架构设计】架构设计规范

架构设计规范

前言

有人说：一千个人眼里有一千个哈姆雷特，每个人对“架构”的理解亦然，业务架构的使命是面向复杂系统构建，降低复杂度，更好地规划系统，承担业务与技术之间的桥梁，重要性不言而喻，架构本质上没有好坏之分，只有是否合适，业务架构也会随着业务的增长与演变，不断完善。古人云：没有规矩不成方圆，为了进一步规范和统一公司业务架构设计、系统命名、系统结构、模块划分、技术选型等，保证运维人员、开发人员、测试人员、业务人员对系统架构有一个全局认知和共识，特此推出《架构设计规范》

业务架构设计评审清单：

名称	新项目是否必须	已有项目是否必须
技术选型	Y	N
业务架构图	Y	N
系统模块划分	Y	N
业务时序图	Y	Y

概要设计评审清单：

名称	新项目是否必须	已有项目是否必须
用例图设计	Y	N
ER图设计	Y	N
状态图设计	Y	N

详细设计阶段需要提供评审清单：

名称	新项目是否必须	已有项目是否必须
数据库设计	Y	N
接口时序设计	Y	N
接口设计	Y	N

技术选型规范

在建筑行业，如果需要构建一座大厦，首先打地基，然后再搭建主框架，最后才是添砖加瓦，系统建设同理，中间件是应用系统的基础设施，是应用的装备和工具，中间件的建设是大中型系统建设的前提。因此在搭建一个新应用时，我们需要首先确定，需要使用哪些技术。目前公司内部使用的技术如下：

名称	选型
JDK	jdk1.7，特殊情况下需要使用jdk1.7以上版本，需要经过架构组确认
缓存	redis 主从模式
消息队列	rocket mq
关系型数据库	mysql 主备
配置中心	disconf
RPC框架	dubbo
监控平台	cat
日志平台	elasticSearch+filebeat+kibana
应用容器	tomcat 7、8
定时任务	elastic-job
负载均衡	tengine
规则引擎	drools
文件系统	oss
协调服务	zookeeper
非关系型数据库	mongodb

如需在项目过程中使用新的技术需要提前与架构组确认，并确认具体业务场景，由架构组统一规划。

中间件引进流程：

调查——>试用——>选型——>深入研究——>Demo——>Wiki——>分享推广——>业务系统试用——>改进完善——>小规模推行——>改进完善——>大规模推行

业务架构图设计规范

系统架构 = 系统 + 架构。应用就是系统的最小单元，应用分级和应用编排则构成了应用关系即应用的架构，它有利于应用的管理、交互和追踪。业务架构图即用画图的方式来描述系统及系统间联系，可以说是一图抵万言，架构图能够清晰的展现，业务系统在公司整体架构中的位置、职责，以及他们直接的关系，在业务架构图的设计过程中，我们应遵循以下几点规范：

时序图应包含业务所涉及到的所有参与者
架构图使用不同颜色对前端、Web应用，中台服务等做区分，让人一目了然
需要对本次设计的业务系统做职责和边界的描述
需要在架构图中体现出变更的内容

示例：

应用命名规范

一般要求： 选择有意义的名字，能快速地传达该应用的用途，多个字母间使用“-”连接
实际应用举例：

http接入层：以“-web”结尾，比如：sdk-web,shop-mall-web
业务系统：以“-ms”结尾或者具体的业务模块，比如：shop-mall-order、share-mall-ms
管理系统：以“-console”结尾，比如：shop-mall-console
商户服务平台：以“-merchant”结尾，比如：shop-mall-merchant
中台服务、基础服务：使用具体的服务名称，命名应与具体业务无关，比如：message-center
服务提供者：多个字母间使用“-”连接，以“-facade”结尾，比如：shop-mall-order-facade

系统模块划分规范

有些系统不仅需要对外提供http接口，还需要对内提供rpc接口，需要将系统划分为web层和core服务层，以钱包系统为例，wallet-web对外提供http接口，wallet-core对内提供rpc服务，系统还可以对提供的rpc服务做细分，将rpc服务拆解成更小的粒度，以基础商城为例，将mall-core拆分成mall-show、mall-order、mall-pay，需要具体情况具体分析。系统工程生成可使用maven-archetype进行生成，保证各项目代码结构一致
示例：