《microservice design》

一、原文：

Each service can allow teams to choose different technology stacks or data storage technologies within them, of course, considering other factors as well. However, it is not practical to allow teams to choose any technology stack without limitations. For example, if you need to support 10 different technology stacks, you may encounter difficulties in recruitment or face challenges in personnel exchange between different teams. Similarly, if each team chooses completely different storage technologies, you may find yourself lacking sufficient expertise in all of them. Take Netflix as an extreme example. They have mature usage guidelines for storage technologies like Cassandra and believe that it is more important to build related tools and cultivate experts around Cassandra, rather than using the most suitable technology for specific tasks. Netflix prioritizes scalability as the most crucial factor. However, you can draw your own understanding from this example. However, things can become messy when it comes to interactions between services. If one service decides to expose a REST interface via HTTP, another service uses protocol buffers, and a third one uses Java RMI, consumers of these services would need to support various forms of interaction, which can be a nightmare. This is why I emphasize that we should "worry about the interaction between services and not overly focus on what happens within each individual service."

二、翻译：

在每个服务内部，团队可以选择不同的技术栈或数据存储技术，当然也要考虑其他因素。然而，无限制地允许团队选择任何技术栈是不实际的。例如，如果需要支持10种不同的技术栈，可能会在招聘上遇到困难，或者在不同团队之间的人员交流上面临挑战。同样，如果每个团队选择完全不同的存储技术，可能会发现自己对它们都没有足够的专业知识。

以Netflix为极端例子。他们对于像Cassandra这样的存储技术有成熟的使用指南，并认为围绕Cassandra构建相关工具和培养专家比针对特定任务使用最合适的技术更重要。Netflix将可伸缩性作为最关键的因素。然而，你可以从这个例子中得出自己的理解。

然而，当涉及服务之间的交互时，情况可能变得混乱。如果一个服务决定通过HTTP暴露REST接口，另一个服务使用协议缓冲区，第三个服务使用Java RMI，那么这些服务的消费者将需要支持各种形式的交互，这可能会成为噩梦。这就是为什么我强调我们应该“担心服务之间的交互，而不需要过于关注各个服务内部发生的事情”。