# saas

**Repository Path**: exchain/saas

## Basic Information

- **Project Name**: saas
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2018-10-18
- **Last Updated**: 2020-12-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# saas model


#### 微服务划分原则
  * 1.单个微服务只管理一种业务，并且复杂度较低
  * 2.一个业务如果需要调用多个微服务达成，那么每个微服务可以保证自身的业务段完整
  * 3.多个业务共享的流程切面如果是可以抽象共享的，那么这个切面是可以独立成为微服务
  * 4.多个微服务尽量不共享数据库，如果出现，那么该数据库的管理应该独立成为服务
  * 5.如果一个微服务中管理的数据库既包含APP相关，又包含APP无关，那么该微服务应该拆分


#### 数据库的微服务归属原则
  * 1.业务流程相关的数据库，必然由对应微服务管理
  * 2.业务相关的配置数据库，必然由对应微服务管理
  * 3.APP分库需求单无业务相关的配置数据库，应该放入所系统服务中
  * 4.APP无关并且无业务相关数据库应该归属到统一配置服务中



#### 其他规范
* 1.如果数据库是一个配置,那么配置的修改需要有记录，如果该数据库的某类配置只会有一条有效，那么该配置的修改记录可以直接记录入此数据库，并且通过状态区分有效性
* 2.如果业务中的某些参数或者运算结果依据配置而来，那么在业务记录中应该体现对应的原始配置或配置记录id
* 3.运营系统调用其他微服务中进行配置修改时，对应微服务修改完成后应返回新的有效配置或配置修改日志id
* 4.APP无关的读IO频繁、写IO较少的如统一储存和外部行情数据库，当通过rpc获取时，应该本地通过redis制作有过期时间的缓存（ 初期可暂时不考虑）
* 5.当一个业务流程中需要跨微服务进行业务操作时，为了保证业务的容灾和回滚，应该在对应的业务记录上体现这些步骤，并且没完成一步修改一次对应记录的某个状态值(初期暂时不考虑，在云支付已经做了这个)


#### 微服务在不同视角的运行情况
服务名           |    APP配置  |  云支付   |  云结算  |  区块链 |   外部行情  |  统一配置 |   充提    |   所支付  |  所系统  |  文章系统  |   法币交易  |   用户服务 |   记账服务  |  运营管理服务  |   消息  
---------------:|:-----------:|:--------:|:-------:|:------:|:----------:|:--------:|:--------:|:--------:|:-------:|:---------:|:---------:|:---------:|:---------:|:-----------:|:-------    
服务运行的APPID   |      NA    |      0   |     0   |   NA   |     NA     |      NA  |    ANY   |   NOT0   |  NOT0   |     ANY   |    NOT0   |   ANY     |     ANY   |      ANY     |   ANY
平台0的使用       |       Y    |      N   |     N   |    Y   |     NA     |      Y   |     Y    |    N     |    N    |     Y     |     N     |     Y     |      Y    |       Y      |   Y
其他APP的使用     |       Y    |      Y   |     Y   |    Y   |      Y     |      Y   |    Y     |   Y      |    Y    |     Y     |      Y    |     Y     |     Y     |     Y        |   Y



#### APPID=0时为平台服务
  * 对应的记账服务中为平台本身帐号的钱包和相关记账（包括mainaccount的钱包用于服务购买，及subaccount的当为ico为备付金，当为交易所为结算准备金）
  * APPID=0开通的服务有：记账、充提、用户服务
 * APP0下辖的钱包类型有：平台账户用来买服务的HD钱包，ico子账号备付金HD钱包，交易所子账户准备金HD钱包，同时APP0同样有充值提币回笼热钱包等功能



#### 和APPID无关的服务有
 APP配置，平台系统服务、行情服务，区块链服务，统一配置服务




#### 云结算和云支付
  * 云结算和云支付操作记账服务时，传入的APP必然=0，所以会直接修改备付金和准备金！
  * 云结算和云支付实际和APPID有关，只是她的APPID永远为0