在 《微服务架构设计模式》 一书中，作者总结了关于微服务的一些“重点”，原文如下：
中国企业和开发者对微服务架构的热情让我印象深刻。但如同我给所有客户的忠告一样，我想对本书的读者说:
第一，要记住微服务不是解决所有问题的万能“银弹”。
第二，编写整洁的代码和使用自动化测试至关重要，因为这是现代软件开发的基础。
第三，关注微服务的本质，即服务的分解和定义，而不是技术，如容器和其他工具。
第四，确保你的服务松耦合，并且可以独立开发、测试和部署，不要搞成分布式单体(DistributedMonolith)那将会是巨大的灾难。
第五也是最重要的，不能只是在技术上采用微服务架构。拥抱DevOps的原则和实践.在组织结构上实现跨职能的自治团队，这必不可少。
还必须记住:实现微服务架构并不是你的目标。你的目标是加速大型复杂应用程序的开发。
最后，我要感谢中国的所有客户，让我有机会与你们探讨微服务。我还要感谢那些让我能够讨论技术而不用学说中文(这可比微服务难多了)的同传翻译。我希望你会喜欢阅读这本书，它会教你如何成功开发微服务。我期待着再次访问中国，与我的读者见面，帮助更多企业客户实施微服务架构。
ChrisRichardson2019年2月13日
核心思想 第二 和 第五，总结为：微服务不只是技术问题， 也是团队结构问题。
想要理解这句话，可以先了解下著名的康威定律：
康威第一定律
Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.– Melvin Conway(1967)
组织设计的产品/设计等价于这个组织的沟通结构。
用人话来说，就是你组织是啥德行，产品就是啥德行。从这个角度上来说，阿里的产品架构都非常严谨，中规中矩，先顶层设计，后逐步细化。所以钉钉能够成功也来源于阿里本身的组织架构。
康威第二定律
There is never enough time to do something right, but there is always enough time to do it over。
时间再多一件事情也不可能做的完美，但总有时间做完一件事情。
这个定律在概念上就是“敏捷编程”，即持续集成持续部署持续交付，devops。
康威第三定律
There is a homomorphism from the linear graph of a system to the linear graph of its design organization.
线型系统和线型组织架构间有潜在的异质同态特性。
异质同态指的是系统和组织虽然是两个东西，但是有相同的结构。所以系统是啥样，组织也就得变成那个样子。
比如公司如果是单体架构，那就只需要一个开发组即可；但是如果是前后端分离，那么必然就会拆分为前端组和后端组，分别进行管理。这就是所谓的异质同态。
如果系统和组织的结构不匹配，那么将会是灾难。你想象一下系统是前后端分离，但是压根就没拆分前后端的岗位是啥情况？
康威第四定律
The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems。
大的系统组织总是比小系统更倾向于分解。
当系统功能越来越多，流量越来越大，垂直扩展无法解决这些问题。进而走向了水平扩展到道路，那么想要支持水平扩展，就需要解决很多基础问题，比如会话状态，比如lb等等。当你真的支持了水平扩展了，你自然而然就会发现，有些业务访问量很大，需要的资源很多，但是有些很小，业务上也无需塞到到一个服务里面，这时你就会想到去拆分了。拆分后，你反而需要解决更多的问题。所以这一定律也就更考验到服务拆分的能力。
综上所述，关于微服务架构，本身是服务于系统架构而生，面向日渐复杂的系统架构。
- 拆分微服务的目的应该为：性能伸缩， 运维独立以及团队结构优化。
- 如果你想要为了让团队技术追新儿使用新的微服务技术，为技术而技术，大可不必，springboot 也很香。
- 在大部分的系统架构升级中，往往会带来更多的维护成本，架构一直都是一个取舍，为了解决伸缩性的问题，就要舍弃单体应用的简单性，引入分布式的复杂性。往往 1+1 是 < 2的。
- 实现“高内聚，低耦合”，说得容易，做得费劲。
