有关微服务的技术Docker火热起来之后也进一步升温。一般来说，IT业界，尤其是工程师们更加关心国外专家的技术文章。但事实上，对于软件项目成功与否来说，往往是企业中人的因素决定结果，企业文化因素决定结果，对于微服务架构，则更是如此；因为微服务的分割是从企业业务开始，而不是从软件技术开始。本文由轻元科技首席架构师王昕翻译，如有疑问，欢迎留言讨论。
似乎每过五到十年，在软件行业，特别是企业集成或者是企业应用领域，就会出现一些新的方法论或架构方式，声称能够让你的效率变快10倍，让你的企业更加敏捷、灵活、快速应对变化，或者给你带来一些其他什么令CIO、CTO们随时原意花钱的特性。我们经历过Enterprise Application Integration，Web Service，SOA，基于组件的架构SCA，企业服务总线ESB等等。
而今天我们遇到的新东西就是：微服务，但是猜猜怎么着？你可能没法把微服务架构玩儿好。
坦白地说，我这么说不是给你尝试新东西的热情泼冷水。微服务也的确是有合理逻辑的，并且它是通过观察多年来那些失败的项目而总结出来的。但是，要想让这种架构成功（或者任何其他架构）是要有一系列前提条件的，而这些东西，根据我的观察，在很多广泛应用微服务的地方都还是没有的。
不论以任何方式，鼓吹Spring Boot也罢，推行DropWizard也好，应用容器也罢；你不能仅仅因为不再用应用服务器就说你是微服务架构。
而微服务架构能在像Netflix和亚马逊这些地方工作得好，似乎是这些企业本身有一些特性组合起来才能行的。然而问问你工程部门的VP，再问问你计算部门的主管，问问他们，他们内部的团队组织结构是否像亚马逊一样。他们的团队组织结构最终很可能会搞砸，因此你的公司根本无法把微服务架构玩儿好。
大多数公司的组织架构不适合微服务架构我们都听说过Conway法则（译者注：软件系统架构最终会跟企业组织架构一样），这是你玩儿不了微服务的最主要的原因。
企业中人的因素会决定结果，企业文化的因素会决定结果，纸面上的流程和纸面上的结构决定不了结果。如果你有UI团队，DB团队以及服务团队，每个都只关心于自己那一块儿，你最后得到就是像传统的3Tier应用一样的系统，而不会是微服务架构的系统。技术团队专注于自己的技术这本身没什么问题。但是技术团队上面的树状组织结构和一大票经理对于基于微服务的团队是个障碍。
REST并不是银弹REST很好！我很喜欢这个概念，一般来说对与企业应用领域我们说REST，也就是说它的HTTP协议实现方式。我很高兴可以远离SOAP。HTTP和REST接受范围广、有很棒的工具，网络设备和代理服务器在设计之初就都是考虑了HTTP和REST的…但REST不是银弹。
模块化应用很难服务应该多大？服务分解应该多深入？如何实现单一职责？如何分析好领域驱动设计（DDD）的限定上下文（Bounded Context）等等。这些东西在实践中都很难搞对。多做几次，通过失败学习如何避免坑是最好的办法（我的观点），但模块化你的应用和你的领域模型都是不容易的。
我们还不太明白如何做基于事件的架构
为什么我们还在用RPC将所有模块连接起来？这一现象最突出地提醒我，我们还不知道如何正确的做基于事件的架构，也提醒我，当一种新的架构风格出现，我们一定还会要重复我们以前的错误。另外，微服务不等于REST（译者注：不是说把同步调用从RPC变成REST或者通过REST模式实现RPC就是微服务了）。
好吧，这篇文章变成了一整篇的抱怨，但我不过是为了给关于微服务的讨论加入点儿真正的实际情况。最后，在进程级别隔离服务和系统还不是真正的松耦合或解耦的系统。运行时的耦合性还可能仍然存在，甚至可能耦合更多。不要介意有关分布式计算的那些错误认识（译者注：网络没有延时，调用永远会成功等等）仍然处处存在。那么也许每次当我们重新发明架构风格的时候，我们应该以经验教训总结的方式来做说明？