欢迎在GitHub上关注FinTx的开源账务系统：fintx-accounting

欢迎在GitHub上关注FinTx的开源账务系统：fintx-accounting

正确时金融系统设计的第一原则，不能保证正确其他原则都无从谈起。

2 安全

对金融数据做到防篡改，防解析，防获取。默认不信任任何外来请求，数据…没有用户会愿意使用一个不安全的金融系统。

3 合规

在国内的大环境下，对于有一定规模或有一定追求的金融公司，监管是不得不面对的问题。尤其是对互联网金融企业，针对一些国家，地方的互联网监管规范要求，如《互联网金融统计制度》和其他一些报送要求。

4 可追溯

对所有的登陆，退出，请求，响应，业务处理，状态变更都要记录历史信息。方便风控，审计，追溯，定位。

4 一致

领域（服务）内强一致性与领域（服务）间最终一致性相结合使用。系统间完善对账机制与业务监控。

6 补偿

无论服务内还是服务间，带超时的同步接口，查询/异步通知接口，撤销接口，配合定时补偿机制，结合使用。

7 幂等

保证服务调用的幂等性，业务处理的幂等性，不能保证幂等的地方需要请求去重，反馈去重，业务去重，对每一次变化，才能保证结果正确。

5 识别

对每一次引起变化的事件，都要可识别，request要有RequestId，responseId，业务要有businessId…对有状态的业务要识别尽可能多的状态（有人提到MECE分析法，深以为然），并记录详细的状态迁移信息。作到一切事件，状态皆识别。

9 内外控

风控针对所有用户。不仅包括所有客户，也包括所有内部用户。

欢迎在GitHub上关注FinTx开源金融系统：FinTx

• 1 全局唯一
  系统设计中对ID的唯一性需求非常普遍。尤其在分布式系统中，要辨别每一次请求是否重复，每一笔业务是否重复，都要求有唯一的ID来识别。对待系统问题查找，审计等有唯一的ID都可以大大简化工作难度和工作强度。
• 2 分布式：
  能在本地分布式生成，不用经过网络获取。没有中心单点多点，不依赖于第三方，无限制扩展。这样才能保证ID最大的可靠性和便利性。
• 3 有序递增
  ID有序对数据检索极为重要，现代数据库一般都采用B+树索引进行数据检索，有序的ID可以极大提升数据库的效率。递增则可满足排序需求。
• 4 时间相关
  ID与时间相关不仅能保证有序递增的，也便于冷热数据的分离。时间相关的ID生成都会面临时间回调问题，要注意处理（保留上次的时间戳，和本次的时间戳比较）
• 5 长度短
  ID长度越短其读写效率越高占用空间小，并且ID都会作为索引列，ID越短期生成的索引占用空间也越小。不考虑其他情况的前提下64bit的long型是最佳选择。
• 6 高性能
  可能的条件下性能尽可能高，以满足大规模超大规模交易需求。单点每秒百万以上的性能才能称为高性能。
• 7 有内涵
  ID的每一部分都有含义，比如包含时间 机器甚至业务信息，便于跟踪定位。尤其在分布式系统下，对线上问题查找原因有极大的帮助。

目前有如下一些主流的ID生成方案

1 MySQL自增主键 autoincreasement id

在MySQL中单表自增主键是最高效的数据库索引，通过单库顺序自增或者多库设定不同的offset和increament来保证ID唯一性。但要在数据存入之后再从数据库取回，不便且面临网络可靠性的风险。默认性能不高单库很难突破千/s级别，多库情况下扩展困难。
优缺点：

• [X] 全局唯一
• [] 分布式
• [X] 有序递增（仅单库）
• [] 时间相关
• [X] 长度短
• [] 高性能
• [] 有内涵

2 数据库Sequence

MySQL并不像DB2 oracle有现成的Sequence特性。它是通过数据表+数据库函数方式实现的Sequence。同样也可以通过设定“current_value”和“increment”的方式多库生成。具体方法网上很多但是大部分都是有问题的，并发条件下会有重复ID。这里提供一个完整的方案 t_sequence.sql。默认性能不高也是很难突破千/s级别，多库扩展困难。但是可以使用获得的ID做基础，在本地附加本地顺序号进行二次分配提高性能。如获取1则在本地可分配[1000,1999]以此提高性能，实现会麻烦一些。
优缺点：

• [X] 全局唯一
• [] 分布式
• [X] 有序递增（仅单库）
• [] 时间相关
• [X] 长度短
• [] 高性能
• [] 有内涵

3 Redis

利用Redis单线程模型，获取自增ID。与数据库Sequence类似，也可通过使用不同初始offset和increment来扩展。不过引入了对Redis的依赖。默认但节点性能万/s-十万/s，同样可进行本地二次分配。
优缺点：

• [X] 全局唯一
• [] 分布式
• [X] 有序递增（仅单库）
• [] 时间相关
• [X] 长度短
• [] 高性能
• [] 有内涵

4 UUID

UUID有不同的版本，常见version 1 和 version 4。参见 RFC4122。UUID长度32字符。
UUID version 1 是基于时间 机器地址 本地序列号构造。
UUID version 4 是基于安全随机数算法构造的，是jdk默认的UUID实现。
优缺点：

• [X] 全局唯一
• [X] 分布式
• [X] 有序递增（仅version 1，单节点）
• [X] 时间相关（仅version 1）
• [] 长度短
• [X] 高性能
• [] 有内涵（仅version 1）

5 snowflake

64bit的long型分布式ID生成。ID中包含时间戳和自增序列。但是依赖于中心分配DataCenterID 和 Worker ID
优缺点：

• [X] 全局唯一
• [] 分布式
• [X] 有序递增（单节点）
• [X] 时间相关
• [X] 长度短
• [] 高性能
• [X] 有内涵（仅时间戳有意义）

6 ObjectId

MongoDB使用12byte数据结构，16进制编码24个字符。结构上与UUID version 1类似，但是做了一定的改进。

虽然由于inc采用随机数初始值大大降低了重复的可能性，但是由于machine采用hash值，理论上还是有可能产生重复ID。可能是考虑到inc随机数初始值的前提下可能性不大，且inc递增使时间回调有一定容忍性（回调n秒时峰值不超过2^24/(n+1)的前提下依能保证唯一），ObjectID也没有考虑时间回调的问题。一切系统放大到一定规模的时候，不太可能出现的问题就一定会出现。
优缺点：

• [] 全局唯一
• [X] 分布式
• [X] 有序递增（单节点）
• [X] 时间相关
• [] 长度短
• [X] 高性能
• [X] 有内涵

FinTx的分布式唯一ID生成方案

fintx-identifer采用了类似ObjectId的方案，使用15byte数据结构，将machine扩展为48bit使网卡MAC地址作为机器唯一标识保证绝对唯一。处理了时间回调问题。并且采用64进制（Base64）编码字符串，将长度控制在20个字符。由于Base64的字符在UTF-8编码下只占1byte。UTF-8编码的20字符（20byte）唯一ID比UUID的32字符(32byte)减少37.5%。

优缺点：

• [X] 全局唯一（全球唯一）
• [X] 分布式
• [X] 有序递增（单节点）
• [X] 时间相关
• [] 长度短
• [X] 高性能
• [X] 有内涵

欢迎在GitHub上关注FinTx开源的唯一ID生成方案：fintx-identifer

欢迎在GitHub上关注FinTx开源金融系统：FinTx

欢迎在GitHub上关注FinTx的开源账务系统：fintx-accounting

在获取账户余额时，比较最终更新日期与当前日期，当前日期>=更新日期，则取余额，否则取上期余额。
在更新账户余额时，比较最终更新日期与当前日期。当前日期<更新日期（后详），则更新上期余额和余额。当前日期=更新日期，则更新余额。当前日期>更新日期,则设置上期余额=余额再更新余额，最后设置更新日期=当前日期。
由上可见，在双余额的条件下不太关心系统什么时候日切，只要按照交易系统传入的当前日期与更新日期做比较即可。
对更新余额的情况分两种–动账更新和批量更新。
动账更新时在每个账户需要进行账务处理时才更新账户余额，批量更新是每天日切之后对交易日期为昨日的账户统一更余额。动账更新的方式对系统资源占用更少但是对依赖于余额数据的批量来说会相对复杂，批量新会做大量无意义的处理，并且在日切后处理也无法完全保证账户持续可用（更新时要锁定虽然时间可能很短），但是对有依赖于余额数据的其他批量来说会更简单。FinTx开源的账务系统中选择了动账更新的方式，并且对余额获取提供方式提供了封装好的函数供全局调用。
当然账务系统由于其特定的领域特征，7X24的实现更复杂一些，但是原理相同。

这里也是一个简化模型引入了借贷发生额有时间再详细写，完整实现请先参考FinTx的开源账务系统。fintx-accounting

补充一份关于7X24服务实现的文档银行核心系统7x24方案参考，来源于网络，如有侵权请联系。
欢迎在GitHub上关注FinTx的开源账务系统：fintx-accounting

0)表结构:

1
2
3
4
5
6
7

CREATE TABLE `t_acctsn_custno_pkid` (
  `CustNo` char(20) COLLATE utf8_bin NOT NULL,
  `CustType` char(2) COLLATE utf8_bin NOT NULL,
  `AcctSN` char(8) COLLATE utf8_bin NOT NULL,
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

1)表数据

2)问题程序示意

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

int concurrency = 5;
for (int c = 0; c < concurrency; c++) {
new Thread(new Runnable() {
@Override
public void run() {
while (true) {
Connection conn = null;
try {
conn = DBUtil.getTxnConnection();
PreparedStatement ps = DBUtil.getPreparedStatement(conn,
"select acctSN+1 from t_acctsn_custno_pkid where custNo = ? for update");
ps.setString(1, "0000001");
ResultSet rs = ps.executeQuery();
DBUtil.closePreparedStatement(ps);

ps = DBUtil.getPreparedStatement(conn,
"update  t_acctsn_custno_pkid  set acctSN=?  where custNo = ? ");
ps.setString(1, acctSN);
ps.setString(2, "0000001");
ps.executeUpdate();
DBUtil.closePreparedStatement(ps);

DBUtil.closeTxnConnection(conn, true);
} catch (Exception e) {
e.printStackTrace();
if (null != conn) {
DBUtil.closeTxnConnection(conn, false);
}
}

}
}

}).start();

new Thread(new Runnable() {
@Override
public void run() {
while (true) {
Connection conn = null;
try {
conn = DBUtil.getTxnConnection();
PreparedStatement ps = DBUtil.getPreparedStatement(conn,
"select acctSN+1 from t_acctsn_custno_pkid where custNo = ? for update");
ps.setString(1, "0000002");
ResultSet rs = ps.executeQuery();
DBUtil.closePreparedStatement(ps);

ps = DBUtil.getPreparedStatement(conn,
" update  t_acctsn_custno_pkid  set acctSN=?  where custNo = ? ");
ps.setString(1, acctSN);
ps.setString(2, "0000002");
ps.executeUpdate();
DBUtil.closePreparedStatement(ps);

DBUtil.closeTxnConnection(conn, true);
} catch (Exception e) {
e.printStackTrace();
if (null != conn) {
DBUtil.closeTxnConnection(conn, false);
}
}

}
}

}).start();

3) MySQL死锁日志

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

------------------------
LATEST DETECTED DEADLOCK
------------------------
2015-12-31 15:34:23 7fb7cdabb700
*** (1) TRANSACTION:
TRANSACTION 336633, ACTIVE 0 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 360, 2 row lock(s)
MySQL thread id 102345, OS thread handle 0x7fb7cdc41700, query id 1133481 172.16.5.15 root Sending data
select acctSN+1 from t_acctsn_custno_pkid where custNo = '0000001' for update
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 810 page no 3 n bits 72 index `PRIMARY` of table `checkaccount`.`t_acctsn_custno_pkid` trx id 336633 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 8; hex 8000000000000002; asc         ;;
 1: len 6; hex 0000000522f0; asc     " ;;
 2: len 7; hex 31000001721bc8; asc 1   r  ;;
 3: len 20; hex 3030303030303220202020202020202020202020; asc 0000002             ;;
 4: len 2; hex 3030; asc 00;;
 5: len 8; hex 3135343434202020; asc 15444   ;;

*** (2) TRANSACTION:
TRANSACTION 336632, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 360, 2 row lock(s)
MySQL thread id 102340, OS thread handle 0x7fb7cdabb700, query id 1133491 172.16.5.15 root updating
update  t_acctsn_custno_pkid  set acctSN='15445'  where custNo = '0000002'
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 810 page no 3 n bits 72 index `PRIMARY` of table `checkaccount`.`t_acctsn_custno_pkid` trx id 336632 lock_mode X locks rec but not gap
Record lock, heap no 3 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 8; hex 8000000000000002; asc         ;;
 1: len 6; hex 0000000522f0; asc     " ;;
 2: len 7; hex 31000001721bc8; asc 1   r  ;;
 3: len 20; hex 3030303030303220202020202020202020202020; asc 0000002             ;;
 4: len 2; hex 3030; asc 00;;
 5: len 8; hex 3135343434202020; asc 15444   ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 810 page no 3 n bits 72 index `PRIMARY` of table `checkaccount`.`t_acctsn_custno_pkid` trx id 336632 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
 0: len 8; hex 8000000000000001; asc         ;;
 1: len 6; hex 0000000522f1; asc     " ;;
 2: len 7; hex 32000001b423cc; asc 2    # ;;
 3: len 20; hex 3030303030303120202020202020202020202020; asc 0000001             ;;
 4: len 2; hex 3030; asc 00;;
 5: len 8; hex 3537323520202020; asc 5725    ;;

*** WE ROLL BACK TRANSACTION (2)

4) MySQL数据库隔离级别

RC(READ COMMITTED)

2 知识准备

• 1 一条当前读的SQL语句，InnoDB与MySQL Server的交互，是一条一条进行的，因此，加锁也是一条一条进行的。先对一条满足条件的记录加锁，返回给MySQL Server，做一些DML操作；然后在读取下一条加锁，直至读取完毕。
• 2 RC级别下，由于custNo列上没有索引，因此只能走主键索引，进行全部扫描。主键索引上所有的记录，都被加上了X锁。无论记录是否满足条件，全部被加上X锁。既不是加表锁，也不是在满足条件的记录上加行锁。
  在实际的实现中，MySQL有一些改进，在MySQL Server过滤条件，发现不满足后，会调用unlock_row方法，把不满足条件的记录放锁 (违背了2PL的约束)。这样做，保证了最后只会持有满足条件记录上的锁，但是每条记录的加锁操作还是不能省略的。

3 死锁分析

0)死锁日志分析

• (1) TRANSACTION (select acctSN+1 from t_acctsn_custno_pkid where custNo = ‘0000001’ for update) 共需3个锁(LOCK WAIT 3 lock struct(s)),其中1个表级意向写锁 IX ,2个行锁(2 row lock(s))。发生死锁时在尝试获取主键索引上(index PRIMARY) 某一行的X锁(table checkaccount.t_acctsn_custno_pkid trx id 336633 lock_mode X locks rec)
  这一行的内容为 1 0000002 00 15444
  ( 0: len 8; hex 8000000000000002; asc ;;
  1: len 6; hex 0000000522f0; asc “ ;;
  2: len 7; hex 31000001721bc8; asc 1 r ;;
  3: len 20; hex 3030303030303220202020202020202020202020; asc 0000002 ;;
  4: len 2; hex 3030; asc 00;;
  5: len 8; hex 3135343434202020; asc 15444 ;;
  注意asc后的内容为行中每列的内容的ASCII码)
• (2) TRANSACTION (update t_acctsn_custno_pkid set acctSN=’15445’ where custNo = ‘0000002’) 共需3个锁(LOCK WAIT 3 lock struct(s)),其中1个表级意向写锁 IX ,2个行锁(2 row lock(s))。发生死锁时在已经持有主键索引上(index PRIMARY) 某一行的X锁(t table checkaccount.t_acctsn_custno_pkid trx id 336632 lock_mode X locks rec)。这一行的内容为 1 0000002 00 15444。并且发生死锁时在尝试获取主键索引上(index PRIMARY) 某一行的X锁table checkaccount.t_acctsn_custno_pkid trx id 336632 lock_mode X locks rec)。这一行的内容为 2 0000001 00 5725.
  注1：死锁日志中(1) TRANSACTION中并不显示已持有的锁信息
  注2：死锁日志分析中红字部分与表数据中的id列不对应，经过多次实验(2: len 7; hex 31000001721bc8; asc 1 r ;;)这一列asc 后的内容并不显示不固定，有时是数字有时是字母有时是符号，推测与id有关但是显示的并不是id的值，估计与id列类型(id bigint(20) NOT NULL AUTO_INCREMENT,)有关系。

1)事物时序分析

注3：根据前面的知识储备，及对死锁日志的分析，在上表的时序下满足了死锁产生的条件。

4 解决方法

根据以上分析，绕了一大圈解决方法其实很简单 在custNo上加索引即可，其实custNo作为查询条件是应该有索引的，上线的同学疏忽了，造成了比较严重的线上故障，引以为戒。

完善的上线流程是系统稳定的重要保证.

很多中小型的初创公司使用Gitlab管理自己的代码，想必大家在项目的开发上线中也踩过了很多坑。作为一个过来人选择了Gitlab官方推荐的带有环境分支Gitlab flow（Environment branches with GitLab flow）的最佳实践作为基础，为研发、质量保证和运维团队制定了统一的上线流程。

一般原则

• 分支分为永久分支和临时分支，都是在master分支以外建立。
• 永久分支不会被删除，包括开发的分支master，准生产分支pre-production，生产分支production。
• 临时分支分为功能分支Feature和修复分支Fix，在开发完成会被删除。功能分支必须有对应的需求，修复分支必须对应bug。禁止建立其他类型的分支。
• 临时分支的建立需从master分支创建，并在开发过程中实时合并master的变更。
• Feature和Fix在开发人员在开发环境部署测试，master在测试环境中部署测试，pre-production在仿真环境中部署测试，production在生产环境发布。
• 代码的变化，必须由”上游”向”下游”发展。Feature和Fix是master的”上游”，master是pre-production的上游，pre-production是production的”上游”。比如，生产环境出现了bug 或者要开发新的feature，这时就要建一个临时分支，开发完成把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。
• 质量保证团队成员在开发环境进行第1轮测试，在测试环境进行第2轮测试，在仿真环境进行第3轮测试，发布生产环境之后进行最终验收。
• 在代码从临时分支合并发布到master分支的时候必须通过质量保证的第1轮测试和顾问的code review，从master分支提交到pre-production的时候必须通过第2轮测试并在提交后通知运维团队上线日期并提交必要的运维工单，从pre-production提交到production必须通过第3轮测试和经过运维团队的批准，整个上线结果以质量保证最终验收为准。
• 任何不符合上述流程的代码分支创建和合并必须由项目负责人和项目顾问一起多数通过。任何不经过或者减少测试次数的发布必须通知研发 测试 产品团队负责人并经由多数通过。

特殊情况

• 并行进行的项目虽然提交发布时间上会有冲突，但是“代码通常不会冲突”，不同的feature需要同时修改同一段代码的情况概率很低，通常采用cherry-pick发布需要发布的部分即可 。
• 线上故障并且修复代码和已提交未上线的代码有“代码冲突”的，过批准可以从production分支创建临时分支，开发完成提交production之后必须马上提交master和pre-production流程与正常流程相同，但是其他非紧急需求必须为此让路，即故障和紧急需求提交合并到master或pre-production分支之前禁止此分支提交合并代码,合并完成紧急代码之后优先对紧急代码修复的功能进行测试。
• 紧急需求不能遵守一般开发流程的，开发团队原则上不接受或者必须延后开发上线时间，特别紧急情况经过并且开发代码和已提交未上线代码有“代码冲突”的，经批准按线上故障流程处理。
• 未列举情况原则上经过批准可以按线上故障流程处理。

做一些踏踏实实的事情.

Technology is tool, business is king.
技术是业务需求驱动的。用了再高深的技术，不满足正当的需求也是失败的项目。反过来说超出正当的需求而用了高深的技术，虽不一定是失败也是不理智的。用分布式系统为图书馆做个图书管理系统，这基本是只能在学校里发生的事情。当然也不排除是业务革命的可能，比如谷歌图书馆。但是世界上能有几个谷歌图书馆呢。
纵观国内的互联网金融乃至整个互联网行业，浮躁充斥着各个角落。由于高速发展带来的财富效应，资本聚集。即使遭遇寒冬，仍不能让人们冷静下来。在此感染下，催熟了一大批“高级工程师”，“架构师”。他们言必分布式语必微服务，张口cloud，闭口serverless。看了个例子就熟练XXX。“吹水”成了看家本领和最擅长的技能。找一家创业公司，拿着不菲的薪资，干着忽悠老板，忽悠投资人的事。他们从各种地方找各种人用开源软件七拼八凑，用他口中那些技术做了个每天个位数访问量的系统。殊不知，淘宝在2008年（PV2.5亿，会员5000万）之前还基本是一个单一系统。即便考虑技术的进步，PV过千万会员过百万之前还是省省吧。认真把基础的项目划分模块划分做好，分布式服务化都是水到渠成的事。即使是大型微服务化系统也是由一个个单一的节点组成，每一个节点本质都是一个单体系统。单一体系统都没做好就大干快上微服务无异于沙上建塔。其结果可想而知。问题百出，人肉硬扛，累跑运维是肯定的，没准还成本奇高。关键是最终才发现，业务没做好。当然公司最后如何与这些人是其无关，都可以怪公司业务没做好。当然失败的经验也是经验，技术当作成绩可以拿来忽悠下一家公司。
合适的才是最好的。是否合适取决于公司战略，业务，个人能力，团队的水平，和对技术的熟悉程度。对于创业公司来说，面临的问题与有成熟的大公司完全不同。用分布式，自建私有云，上规模的公司有高水平的研发团队，可靠的运维团队，几乎用不完的资源做后盾。这些公司业务完善稳定，技术改造同时不用面临业务的压力。但对创业公司而言，资源有限，人员有限，资金有限，团队水平参差不齐，互相不熟悉。在这种情况下，用最熟练的技术，快速实现业务需求，把业务流程，用户体验作好，精雕细琢。先让业务稳定下来才是首要目标。有了经过业务洗礼的可靠技术运维团队，有了一定的用户量做基础，才有可能支持系统进一步优化。
踏踏实实先做好业务的每一个细节。说来简单，可现实是残酷的。金融企业竟然连一个账务系统都没有，自己收了多少钱，该交多少税，最后赚了多少，哪些产品盈利，哪些产品亏损，一概不知道。拿企业最重要的资金收付来说，钱收的时候到没到，该收的够不够，多收少收怎么办，这些要么都是人工处理，要么根本不管对错。某银消费金融公司与下属企业上百万的款项成了糊涂账，并遭内外合伙骗贷造成巨额亏损。这种事情绝对不是个例。
罗马不是一天建成，好的系统是一步步迭代来的而不是设计出来的。“97%的情况下，过早优化是万恶之源”。有限的资源下，过度的技术设计必然导致业务设计不足，这是自寻死路。对业务需求，技术支撑不足才是初创阶段的主要矛盾。开始就按百亿估值做系统的创业公司，都死了。上来就按百亿级流量做分布式设计的架构师，都跑了。
希望FinTx能为大家提供一个探讨金融业务，架构，设计，技术，法规等话题的场所，并且提供一些能支持当下业务也能扩展未来发展的基础组件。大家一起做一些踏踏实实的事情。