Skip to content

top constraint

Jump to bottom
雷霹雳的爸爸 edited this page Aug 15, 2018 · 27 revisions

顶层约束

接口方面

  • 所有的对内对外的接口均要求使用REST风格设计，使用HTTP协议，内容规格设计为JSON
    • JSON顶层为两个字段：code和data
    • code为number（整数），在HTTP扩展码不足以表达更细节含义时使用，要有辅助文档说明具体含义
    • data为JSON的object，规格根据业务自定
    • 如data中返回集合数据，要有分页（pagination）设计，下辖两个字段
      • total，number（整型），表示不分页的集合总数
      • payload，array，数据集合内容
    • 客户端请求参数为per_page和page，表示返回的结果集大小，以及按这个大小分页是第几页
    • per_page和page均可以省略，省略时认为缺省值分别是10和1
    • per_page超过服务端能处理的最大值时，按服务端最大值返回
    • page值给出小于1则按1返回，给出的值大于指定per_page的最大页码值，则返回最后一页

多租户相关强调

  • 【强制】每一个涉及特定租户功能的web接口都要验证必选参数tenant_alias，指明是操作的哪一个租户，根据接口功能确定是否强制要求给出机构标识

SCM

  • VCS 使用 git
  • 构建管理使用 maven
  • 如有二方库管理需求，使用git submodule进行管理，即不以任何方式导入maven中心库没有的jar包
  • IDL式的组件，版本仓库中仅保留IDL源文件，代码生成依赖 maven

后端架构层面的选型及规范要求

  • 要求整体架构使用前后端分离的方式实现
  • 后端使用微服务架构风格进行设计
    • 各服务选用Spring Boot来做项目基础框架
      • 使用Spring Boot Initializer生成项目脚手架，保留maven wrapper到git仓库
    • 使用 Spring Cloud Eureka 做注册中心
    • 和认证系统对接使用OAuth2协议
    • 服务对外认证由网关层统一处理
  • 根据业务关联性纵向拆分服务，对于服务及服务间关系的有如下设计层面的指导性原则：
    • 每个服务按需来选用自己的持久化存储基础设施，基础设施选型可包含不限于以下选型：MySQL，MongoDB，Neo4j等，但同一类型的存储不要选择多个，比如关系型数据库，不要同时使用MySQL和PostgreSQL
    • 每个服务按项目初始的开发人员最大产能习惯或倾向性来选择持久层框架，但不要在一个项目中使用多个持久层框架
    • 必须做到仅通过api调用来访问其他服务管理的私有数据
    • 可以为提高效率在不同的服务中做数据冗余设计（持久的，或缓存的），但禁止直接访问其他服务的私有持久化存储地址（不共享存储）
    • 服务间调用可以使用Feign
    • 服务间如有异步调用使用消息中间件选用和kafka或RabbitMQ

关系数据库方面的要求

  • 每个服务的数据库都要支持多租户多机构数据共享存储：
    • 【强制】所有要按租户进行区分的数据表均增加tenant_id字段或有关系表记录与tenant_id关系且tenant_id不能为空
    • 【强制】和机构有关的，需增加 organization_id 字段或有关系表记录与organization_id关系且不能为空

Java 编码规范方面的要求

  • java固定在版本8，目前不要使用9和10的任何特性
  • Java服务开发时，需要的类库版本如果包含在Spring Boot 2.x.x.RELEASE中，则以其BOM为准，不要再另行声明版本号，这方面如有特殊需要，请文档注明
  • 其他方面参考Java编程风格指南文档

组件版本

  • Spring Boot 2.x.x.RELEASE，即确认大版本号，确定是Release版，项目使用Spring Cloud组件则使用Spring Initializer生成，依赖Spring Boot的BOM声明
  • Redis 3.2.12
  • MySQL 5.7.x
  • Kafka 0.11.0.2
  • RabbitMQ 3.7.6

Clone this wiki locally