架构师们常讲的设计定律之中最为重要的是康威定律，康威定律的定义：
> Conway's law is an adage named after computer programmer Melvin Conway, who
introduced the idea in 1967. It states that. organizations which design systems
... are constrained to produce designs which are
现在的架构师总喜欢把最终一致挂在嘴上，好像最终一致是解决分布式场景下数据一致问题的金科玉律。事实上又怎么样呢？
事实上的这些人嘴里的最终一致，往往都是最终不一致。在多个系统之间进行数据传递时，无非通过 RPC 或者异步消息。RPC 能保证一致性么？当 B 系统需要 A
系统提供数据时，想要达到一致的效果，那么在 A call B 时发生失败，那么必须让 A 中的逻辑终止。这样才能够使 B 中的状态或数据与 A
中的完全一致。这样实际上需要让 A 和
微服务模式下，我们的系统中往往需要集成进各种各样的 SDK，这些 SDK 部分来自于非功能性的业务需求，例如 bool 表达式解析，http
router，日期时间解析；一部分来自于对公司内基础设施的绑定，如 MQ Client，配置下发 Client，其它服务的调用 SDK 等等。
一般的观点会认为公司内的 SDK 是较为可靠的，而开源库的稳定性不可控，所以人们在升级公司内部库时往往较为激进，开源库版本升级较为保守。具体到 Go
语言，公司内的库，我们可能会直接指定依赖的版本为 master(
在之前写事故驱动开发的时候，提到过，在企业中的项目进行开发时，只要是自己方便，一个人可以用拆分和收敛同时作为自己的标准。所以大家都是双标狗。
目前业界的微服务方法论一般也没有固定的套路，比如在 《Building Microservice》
一书中，作者也讲到了服务之间协作的时候，可以选择编排(orchestration)和协同(choreography)这两种方式来对服务进行架构。所以在拆分阶段，就没有什么硬性的标准了，每个公司可能风格都有差别，并且都可以阐述出自己的条条以支持自己的架构是“正确”的。
显然，这件事情没有绝对正确的解法。无论哪种拆分方式，都会遇到业务边界的问题。在大企业中，顶着“架构师”头衔的这些架构师们根本就不会管任何实现上的细节。相对较大的业务需求，一般也是一线的
微服务的布道师们特别喜欢鼓吹一个观点：拆分微服务之后，我们可以随意地对小模块进行重构，选择最合适的技术栈，并且如果写失败了随时对这个模块拿其它语言进行重写。这一点被大多数布道师当作微服务的重点优势。
但是布道师们有意地把这样做所带来的问题忽略了，或者更恶意的是，他们明知道有问题，但是不说？啊哈哈。
一个公司业务上有多种语言的话，理论上可以吸引到各种“语言的人才”。这确实不假，并且可以提供给各种语言大佬一个互相掐架的优秀竞技场，只要干掉对手(其它语言的大佬)了，我就可以扩张团队，让团队把所有其它语言的模块用我们擅长的语言重写一遍，善哉善哉。小伙子们一年的事情就都安排上了。
但是显然这种说辞是有问题的。在现行的微服务架构下，除了业务本身的研发人力投入之外，在业务之外的支持系统的研发工作也有很大的工作量，比如典型的，服务发现，熔断，优雅重启，存储系统
client，
