作者回复: 数据库能不拆尽量不要拆，除非万不得已。拆开以后就会面临分布式事务的问题。 但是业务和团队发展到一定阶段，解耦拆分在所难免。数据库拆分是个很大的主题，也是一个体力活，没有一招鲜的办法，就是一个制定拆分计划，按部就班不断执行拆分的过程。一般的思路是先做好服务化(所有应用都不能直接调用数据库，必须通过服务访问)，服务化搞定，有了一层间接抽象以后，才可以考虑数据库拆分。数据库先做好读写分离：数据库端只有写入，然后变更数据同步到其它存储(其它DB/ES/HBase/...)再构建各种读视图。实现读写分离以后，DB只有一个写入端，这时候就可以考虑拆分甚至替换(从双写+比对开始)。拆分之后一定会引入不同数据源之间数据一致性和数据同步的问题，这个时候一定会需要引入可靠消息系统。 所以，根据个人经验，数据库拆分的几个关键是：1). 服务化，2)读写分离，3)可靠消息系统。 关于分布式事务，这个东西其实是具体业务相关，也没有简单一招鲜的框架。思路很多，简单常用的做法是先落地(类似WAL~Write Ahead Log)+子系统执行事务+协调器协调。推荐看ebay架构师写的关于微服务数据一致性的文章，讲得比较全面： https://dzone.com/articles/data-consistency-in-microservices-architecture

作者回复: 服务之间调用(或者网关调后台服务)要做好限流容错，可以采用组件hystrix/resillience4j或者阿里开源的限流容错平台sentinel。 数据一致性，如果短事务要求强一致性，可以考虑阿里开源seata，它是一种2pc的变体实现。也可以考虑基于可靠消息的最终一致性。长事务一般考虑saga模式(类似一种基于可靠消息的协调机制)。

作者回复: 你好，staffjoy里头持久层model的主键id都是用的system-uuid，这个应该是jpa/hibernate生成的uuid，类似java的UUID.randomUUID。 我的理解一般java的UUID.randomUUID就足够了(碰撞只是理论上，实际真碰撞了数据库会报错，也没有大问题)，而且这个是无状态的，根据wikipedia的说法： Only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. Or, to put it another way, the probability of one duplicate would be about 50% if every person on earth owned 600 million UUIDs. 参考： https://stackoverflow.com/questions/24876188/how-big-is-the-chance-to-get-a-java-uuid-randomuuid-collision https://stackoverflow.com/questions/2513573/how-good-is-javas-uuid-randomuuid 当然如果你还是不放心，可以研究考虑分布式unique id生成系统，可以参考twitter snowflake： https://github.com/twitter-archive/snowflake/tree/snowflake-2010 https://github.com/sony/sonyflake

作者回复: 我演示用的是mac系统，不过会介绍windows环境下搭建docker/k8s的一些注意点。课程会采用docker desktop演示，它内置支持k8s，windows安装docker desktop的话，要求win10/64位环境(参考:https://docs.docker.com/docker-for-windows/install/)。如果不是win10的话，要装minikube，或者用vagrant镜像之类会比较麻烦。

作者回复: 这个每家企业做法不同，没有统一标准做法，有些整合在一个表中，通过字段区分，也有的放在不同表中，通过前面的微服务提供统一接口，屏蔽存储细节。

作者回复: 我认为这些HTTP方法和安全没有直接关系。 作为RESTful API，POST/GET/PUT有一些惯例语义，POST常表示创建新业务记录， PUT表示更新业务记录，GET则是获取业务记录。但这个只是一种惯例，不是统一标准。