正文
Verburg：他们还是的。BBC、Netflix、Twitter、Amazon这类公司都是基于微服务架构的，因为它们有横向伸缩的需求。不过这也是大部分IT组织在盲目跟风时无法解决的一个主要问题。“我们真的需要微服务吗？我们的规模需要使用微服务吗？我们的业务需要微服务吗？”对于很多组织来说，答案是否定的。
Posta：引用Branden Williams博士的一句话“再也不存在什么独角兽了，只有那些蹦向胶水工厂的纯种马……”那些互联网公司已经向我们展示过这一点，不过我认为在传统企业领域（FS、制造商、零售商，等等），还是有很多公司正在展示他们使用新技术快步前进的能力。
Bien：最开始没有人知道“微”意味着什么。关于服务大小的讨论是没有意义的。在Java EE里，一个微服务就是一个WAR包，它们通常由“单披萨”团队创建（“双披萨”的团队规模太大了）。
在我看来，继任者是那些基于微服务的企业项目。独角兽来了又去，如果他们只是在刚开始获得成功，那么对于他们的成功就很难给予平价。企业项目会持续更长时间。
InfoQ：有些公司将微服务架构用于全新的应用开发，而有些则关注如何将单体应用迁移到微服务架构。对于这两种情况，微服务的原则是否同时适用于架构师和开发人员？
Richardson：对于大型的复杂系统来说，不管是哪一种情况，微服务架构都是适用的。这要取决于实际的开发场景。例如，对于一个初创公司来说，他们还处在探索业务模型的阶段，那么应该更倾向于使用单体架构。
我认为大部分关键性的业务应用都是大型的复杂单体应用。这些业务无法快速演化，只能循序渐进地将其迁移到微服务架构。
Lewis：我参与过的团队经历过上述两种开发场景。对于迁移开发来说，迁移到微服务通常是有好处的，因为它会给我们带来更多的选择，而且它们包含了之前系统的功能。对于全新的开发来说，就要考虑功能和跨功能需求，以及系统所运行的环境。有时候可以使用微服务架构，但有时候不是必需的。
Verburg：原则都是适用的，但会有一些折衷。完全分解一个单体应用是终极目标，但应用在它生命周期的大部分时间里都会处于微服务和单体共存的状态（有些人把这称为怪物Cthulu的化身）。例如，微服务纯化论者在对单体应用进行迁移时，他们会把原则撇在一边，仍然会“通过存储过程来传递消息”，直到他们把整个应用重构完毕。
这个时候集成测试变得很重要。
Posta：从它们对开发速度的影响来说，这些原则是相似的。你可能会有很多全新的开发项目，不过难点在于如何找到它们与现有系统的结合点，从而对其进行安全的扩展、加速和创新。
Bien： 2016年，大部分用户对于引入微服务架构是抱着很大希望的，他们希望微服务能够带来更好的可维护性，并降低成本。微服务并不缺乏受众，只是有太多人盲从，缺乏好的实现模式。
把一个超级复杂的单体分解成更加复杂的小型单体只会让事情变得更糟。对于已有的项目来说，首先要避免盲从，并重新对领域概念进行分析。将一个精益的单体分解成独立的单元完全是一件可有可无的事情。
对于新项目来说，首先要聚焦在业务逻辑上，在最开始的迭代中可以使用单体。只有在你对优缺点做过明确的了解之后才考虑引入微服务。毕竟交付一个精益的单体应用仍然是最为简单的方案。
不管怎样，新项目和已有项目都需要聚焦业务逻辑。
InfoQ：你们能列出关于微服务的5个要做和5个不要做的注意事项吗？
Richardson：最重要的一点是要知道微服务并非银弹。你需要仔细评估你的应用，并做出权衡。
Lewis：
要做的：
不要做的：
-
不要一下子构建中500个服务，而是先构建合理数量的服务，最起码当前的基础设施能够支撑得起。
-
不要把它们看成银弹。要构建好微服务系统，你需要了解更多的分布式计算知识。
-
不要被厂商的万灵油蒙蔽了双眼，面向服务架构当初就是这么死掉的。
-
不要忽略了可替换性。微服务要小到可以直接被替换掉。
-
不要使用分布式事务。
Verburg：
要做的：
