【.com快译】到现在为止，大多数开发人员都听说过微服务的好处。然而，当涉及到通过将现有应用程序转换为微服务架构来真正“迁移整体”时，您可能会发现设计有效的微服务架构很困难。开发社区花费大量时间讨论为什么采用微服务架构，而不是如何设计微服务架构。本文介绍了设计成功的微服务架构的几种良好实践。我们不会涵盖开发或部署微服务，而是讨论在计划使用微服务架构时要避免的常见错误。1.沉迷于每个功能一个服务大多数描述有效微服务架构的开发人员会告诉您，应用程序的每个方面都应该由不同的微服务提供支持。以支付应用为例，认证应该由一个微服务处理，另一个微服务做支付处理，另一个微服务运行前端，另一个存储和检索数据，等等。将每个应用程序的功能分布到不同的微服务通常是个好主意。但是这个原则很容易被夸大，并且经常阻碍有效的微服务架构的设计。有时，将一种功能与另一种功能区分开来的界线是模糊的。例如，您是否应该将用户注册视为与用户身份验证分开的功能，从而为每个创建单独的微服务？如果您的应用程序将数据存储在多个位置，则每个位置都应该有自己的微服务。服务？或者应该只有一个数据服务来处理所有位置？这些问题的答案是它可能无关紧要。了解一个应用程序将拥有多少个微服务以及每个微服务将处理哪些功能。如果您花太多时间弄清楚如何在您的应用程序中拆分不同的任务，您的工作效率就不会很高。2.微服务做得太小同样，在设计微服务架构时，每个微服务都做得太小是一个常见的错误，因此需要很多微服务来组成整个应用程序。开发者之所以掉入这个陷阱，是因为他们认为微服务越小越好。从某种意义上说，这是真的——将大型应用程序划分为更小的离散单元是提高应用程序可扩展性和可靠性的一种方法。但是如果微服务变得太小，后面开发和部署微服务时，开销会大大增加。每个微服务都需要自己的开发和部署管道（更不用说单独的监控、日志记录和安全操作）。因此，虽然您确实希望您的微服务很小，但您不应该太小，您的应用程序也不应该包含太多微服务。作为一般准则，如果您的应用程序包含十几个微服务，则每个微服务可能太小，您应该组合一些微服务并以不同方式设计架构。3.需要特定的部署解决方案如今，通常的做法是通过容器部署微服务——通常借助OpenShift或其他基于Kubernetes的编排平台。但几年后会是这样吗？很难说。部署技术日新月异，很难知道哪种部署解决方案在未来对您的微服务应用程序最有意义。因此，以需要特定类型的部署技术的方式设计微服务架构是错误的。与其让自己依赖Kubernetes甚至普通容器来部署应用程序，不如设计一个可以在各种基础设施甚至各种操作系统上运行的架构。4.要求所有微服务同时更新您有时会在微服务架构中看到一个错误，即要求如果您更新应用程序中的一个微服务，也更新（或至少重启）其他微服务。如果站在单体系统的角度来看，这种想法是很自然的。但就微服务而言，这种方法意味着你是在自找麻烦。微服务的目的之一是在不影响其他部分的情况下更新、扩展或重启应用程序的某些部分。因此，如果更改一个微服务的状态意味着也更改其他微服务的状态，那么您将失去微服务本应带来的很多灵活性。持续交付也更难，因为您无法在不影响其他服务的情况下推送对一项服务的更新。另一方面，您的微服务不应紧密耦合在一起。在架构设计时尽量避免这种情况：如果一个微服务所依赖的另一个微服务没有运行，它就无法运行。5.忽略日志设计微服务架构时要避免的最后一个陷阱是忽略日志。很容易犯这个错误。您可能认为您可以稍后在为每个微服务编写代码时找出日志，或者您可以将日志记录代理部署到您的微服务环境中，它会收集您需要的所有数据。最好从一开始就将日志记录整合到您的微服务架构中。在许多情况下，这意味着创建一个专门的微服务来从其他微服务收集日志数据。但在其他情况下，每个微服务可能会进行自己的日志记录，将数据重定向到中央位置。无论采用何种策略，目标都应该是确保微服务架构有助于从整个应用程序中收集日志数据，并将其置于中央位置进行分析和存储。结论设计微服务时没有硬性规定。但作为一般准则，上述原则仍将帮助您规划一个微服务架构，该架构提供微服务应该提供的所有好处，而不会像设计不当的微服务架构给开发人员和IT团队带来的麻烦。原标题：设计微服务架构时要避免的5个错误，作者：ChristopherTozzi
