看板的英文就是 kanban 啊，楼主莫非不知道？？？

楼主的需求不是 OAuth2 的菜，应该加密+签名。

delete a,b,c from a left join b on b.aid = a.id left join c on c.bid = b.id where a.id = 'x';

确实是标题错打了，但大家都懂看了。。。。

@Xbluer 原文是「 While monolithic applications prefer a single logical database for persistant data, enterprises often prefer a single database across a range of applications - many of these decisions driven through vendor's commercial models around licensing. Microservices prefer letting each service manage its own database, either different instances of the same database technology, or entirely different database systems - an approach called Polyglot Persistence 」
Martin Fowler 拿传统单体应用和微服务做了个对比，阐明「 As well as decentralizing decisions about conceptual models, microservices also decentralize data storage decisions 」这个观点。根本没提什么「准则」……有些人也太过道听途说不求甚解了吧。

这种沟通不畅的，合作起来太累了……

@tonnycao 一般而言，按领域划分服务是合适的，我举例是有些领域比较大，拆分更多的服务会比较合适。

@Xbluer 是的，「倾向于」。这一点我是认可的，也是尽量这么做的。但绝不能不因地制宜教条地认为微服务必须一个服务一个数据库，某些时候多个服务都属于同一领域，因此会在数据上产生依赖关系。这个时候就是需要多个服务共用一个数据库。

Time Machine 根本没用，还是用云盘存文档吧，onedriver 什么的就很好用。

@hantsy 什么时候微服务有「每个服务都是维护自己的数据库」这种准则了？谁提出来的？依据是什么？

照这个准则行事的话，一个领域只能存在一个服务咯？这显然是不切实际的，譬如用户管理这个领域，就可以具体拆分为：用户、用户组、组织机构、租户、角色、资源、认证等七大模块。这些难道都必须塞到一个服务里面？

一个财务管理领域，也可以分为：账户、流水、收款、付款、退款、对账、提现、开票等等功能，也必须塞到一个服务里面？

@itIsUnbelievable 按实际工资算是没错，但你老板发的现金，你就没证据了。

应届生 10K 不低了呀，制造业 3 年的也不见得能拿到 10K……

这个关注点不应该是后面有没有希望融资成功吗？如果没有融资成功的可能性或者可能性很低，那楼主就是傻，反之就是没有签的傻。

楼上什么旷工的就有点扯了，老板既然提出了这个方案，也就没必要和你们玩这种恶心套路了，否则直接解散不就完了吗，还签什么降薪协议回购协议。

咦，貌似我的理解能力有问题！楼主你到底是哪一边的？不是没签的回去吗？你是签了协议的，不用继续上班的吗？

订单里面没有客户的用户 id ？为啥还要用关系表去存？这里没明白你们是个什么操作

2 楼方案可行。

1 、不算 2pc
2 、不存在 2pc 或 3pc 模式的分布式事务

严格地讲，接收的参数是 dto，返回的数据是 vo 。但我们有时候图省事就是一个 dto……

@programV2 不信的话，你可以把键帽挖出来，看看下面是个什么样子就明白防不防水。

别想着重构了，投入产出比很低的，你领导除非脑子抽了才会支持你。但是，问题还是要解决的，微服务就是天然支持异构系统的。你可以建议领导潮流一把，搞个微服务，然后新项目都用 Java 就完了。