我对微服务这个风向的理解，是在传统软件的设计开发体系基础之上的一种变化，相对于翻天覆地的变革，我更愿称之为一种改良。
微服务和单体并不是一个非此即彼的敌对关系，一个系统中，这两种思路可能会长期并存，并在内外部环境的压力下摇摆。
2012 年构建的 Node.js 单体应用构成了 Medium 的最初技术栈。我们构建了各种卫星服务，但是并没有提出系统化采用微服务架构的策略。2018 年初，随着系统复杂性的提高和团队规模的扩大，我们开始转向了微服务架构，工作中总结出一些如何高效完成这一过程并避免微服务症候群的经验，本文将分享这一经验。
在将单体应用拆分为较小服务的过程中，最难的部分就是单体服务数据库中的数据拆分。要进行这样的拆分，保证数据有一个全程唯一的写拷贝，并且遵循一系列步骤是很有帮助的。
微服务是模式而非技术，服务网格也是一样。这两种概念的区别貌似很难理解。如果我们从 OOP 的角度来看，模式描述的是接口，不是实现。
Istio 的关键能力之一就是为微服务提供安全性和策略控制方面的支持
New Stack 的无服务器企业应用系列，第一篇