用 [TOC]来生成目录：

1.减少跨系统的交互，一个系统尽量只能CURD自己业务域的数据库，不要跨域去操作其他应用的数据。 2.尽量减少IO以及网络的访问，将多次的调用整合在一次操作中完成，尽量减少IO资源的浪费。 3.禁止在操作数据库或者外部接口时候放在循环里面，尽量做成批量接口调用。 4.系统间调用最好是只读，系统间的修改用事件或者消息来实现比较靠谱。 5.对于系统的配置文件，数据库字段修改，或者其他显示复杂逻辑修改；尽量采用增加的操作；而少采用update的操作；update永远比insert成本大的很多 6.系统必须支持横向扩展;底层数据库以及上层应用本身都需要支持扩展来满足未来业务的增长需求。 7.强一致性在微服务架构下不合适，互联网公司一般采用的基于消息【本地消息或者消息微服务；开源的消息中间件只是投递工具】的一致性事务的解决方案。 8.系统需要有区分主次功能，对于主要功能需要加日志层面或者监控层面的告警逻辑；比如资金变动。 9.尽量充分利用CPU的资源，很多情况下，一个应用的CPU资源都利用不充分；瓶颈往往在于IO层面；所以可多引入线程池，让CPU的使用率最大化。 10.系统之间交互，拉的效果往往比推来的稳定性高；选择只读API，而不是读写API，写部分尽量采用事件驱动或者消息驱动。 11.往往内存中的复杂数据结构组装要优先于数据库的链接；

##数据库设计规范

1.尽可能在数据模型上控制业务对象的约束关系；如果通过程序逻辑去保证完整性与一致性，会存在一定的风险。 2.数据模型总的唯一性约束【比如订单号】，一定要在数据库层面得到控制；程序层面的幂等不太安全。 3.尽量少用存储过程；将复杂的业务逻辑抽离到上层应用中；也就是时候尽量使用程序中的数据结构完成复杂的关系运算，避免用存储过程或者复杂的sql语句。因为应用服务器的扩展以及优化的成本往往比DB服务器的成本小的多。 4.sql语句尽量不要依据业务逻辑以及动态拼接的sql字符串，而是采用预编译的方式；否则有sql注入的风险 5.如果主表与子表是一对一的关系，主键尽量相同。 6.数据库是各个业务系统的私有资源；其他系统对于该数据结构应该是透明的；只能通过接口和事件去访问和修改数据。

##外部交互设计规范

1.最好是拉对方的数据比较好；比对方推过来稳定性好； 2.异步消息处理的时候，最好先落地到本地库再进行处理；这样避免消息的丢失，以及消息队列的堆积，导致消息系统挂掉。 3.系统中只能有一种异常：处理中状态等待超时或者重试次数达到最大值。

后续有时间可以单独聊下事件驱动；而不是直接API调用

更多干货： reids开发实战 数据库拆分方案 分布式事务系列 深入浅出spring系列