架构设计规范
前言
有人说：一千个人眼里有一千个哈姆雷特，每个人对“架构”的理解亦然，业务架构的使命是面向复杂系统构建，降低复杂度，更好地规划系统，承担业务与技术之间的桥梁，重要性不言而喻，架构本质上没有好坏之分，只有是否合适，业务架构也会随着业务的增长与演变，不断完善。古人云：没有规矩不成方圆，为了进一步规范和统一公司业务架构设计、系统命名、系统结构、模块划分、技术选型等，保证运维人员、开发人员、测试人员、业务人员对系统架构有一个全局认知和共识，特此推出《架构设计规范》
业务架构设计评审清单：
| 名称 | 新项目是否必须 | 已有项目是否必须 |
|---|---|---|
| 技术选型 | 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进行生成，保证各项目代码结构一致
示例：
其他规范
ER图： 新建表和库需要提供ER图，可参考：https://zhuanlan.zhihu.com/p/26129622
示例：
用例图： 新项目需要提供用例图，可参考：https://zhuanlan.zhihu.com/p/29874146
示例：
状态图： 涉及到有状态变更的需要提供状态图，可参考：http://www.cnblogs.com/ywqu/archive/2009/12/17/1626043.html
业务时序图： 描述业务处理流程，建议使用UML或者ProcessOn画图
示例：
接口时序图： 需要在时序图中标明业务在进行的过程中，调用的接口有哪些，以及本次涉及的改动点
示例：
