这5个错误在设计微服务架构的时候你一定要避开

　　到目前为止，大多数企业开发工作人员已听说了微服务的种种好处，不过，真正通过将现有技术应用程序转换成微服务体系架构以“迁移整体式系统”时，你可能会发现设计一个有效的微服务架构困难重重。开发社区没有花大量的时间来讨论如何设计，而是讨论为什么采用微服务架构。

　　本文主要介绍了设计成功的微服务架构的几个优秀社会实践，我们不会介绍开发或部署微服务，而是通过讨论计划使用微服务系统架构时应避免的常见错误。

1. 痴迷于每项功能有一个服务
　　有效对于大多数开发人员描述的微服务架构，他们会告诉你的应用程序功能的各个方面应该由不同的微服务支持。例如支付应用程序，认证应该是一个微处理服务，支付是另一个微服务进行处理，前端又是一个微服务运行，另一个存储和检索数据，等等。
　　主要的应用程序设计为分配给不同的微服务功能通常是一个好主意。但是这个基本原则很容易过犹不及，往往会阻碍设计进行有效的微服务系统架构。
　　有时，区别一项功能与另一项功能的界线很模糊， 例如，您是否应该将用户注册视为与用户身份验证不同的功能，因此为每个功能创建单独的微服务？如果存储在多个位置的应用程序数据，每个位置都应该有自己的微服务？还是应该只有一个数据服务来处理所有的位置？
　　这些问题的答案是，这可能无关紧要。 找出一个应用程序将有多少微服务，以及它将处理哪些功能。 如果你花了太多的时间来找出如何在应用程序中分割不同的任务，那么它的工作效率就不会很有效。
2. 微服务做得过小
　　同样，设计微服务系统架构使每个微服务过小。因此我们需要企业众多微服务来组成整个应用程序是常见的错误。
　　开发工作人员之所以遇到这个陷阱，是由于没有他们可以认为微服务越小越好，从某种意义上可以说是对的——将大型企业应用系统程序分成较小的离散单元是为应用程序不断提高可扩展性和可靠性的一种方法。
　　但是，如果微服务变得太小，开发和部署微服务的成本将在以后显著增加。每个服务都需要有自己的开发和部署管道（更不用说单独监控，个人日志和安全操作了）。
　　因此，虽然你确实我们希望微服务小点，但不应该选择过小，也不应该让应用系统程序含有太多的微服务。 一般情况下，如果您的应用程序由十几个微服务组成，每个微服务可能太小，则应该合并微服务，以不同的方式设计体系结构。
3. 需要特定的部署解决方案
　　如今的常见做法是通过容器来部署微服务——通常借助OpenShift或另一种基于Kubernetes的编排平台。
　　但几年后还会是这样吗? 我不知道。 部署技术在不断地更新，很难知道哪种部署解决方案对您的微服务应用程序来说是最合理的。
　　因此，设计微服务架构的方式需要特定类型的部署技术是错误的。你不应该让自己依赖Kubernetes、甚至普通的容器才能部署应用程序，而是应设计一种可以在各种基础架构上、甚至可以在各种操作系统上运行的架构。
4. 要求同时更新所有微服务
　　有时候你看到微服务架构的错误要求：如果一个微服务更新应用，同时也要更新（或至少是重新启动）其他微服务。
　　如果从整体式系统的角度来看，这种想法很自然，但在微服务方面，这种做法意味着你是在自找麻烦。微服务的目的一方面是在不影响其他部分的情况下，更新、扩展或重新启动应用程序的某些重要部分。
　　因此，如果改变微服务的状态也意味着改变其他微服务的状态，那么您将失去微服务带来的灵活性。也更难以持续交付，因为万一推动服务升级，你无法做到不影响其他服务。
　　另一方面，你的微服务不应太紧密地耦合在一起。 在设计结构时尽量避免这种情况：如果您依赖的另一个服务没有运行，则服务无法运行。
5. 忽视日志
　　设计微服务系统架构时要避免的最后一个陷阱是忽视日志。
　　这个错误很容易被忽视， 当你为每个微服务编写代码时，你以为在以后搞清楚日志，或者你能够到一个微服务环境部署日志代理，它将能够收集你需要的所有数据。
　　最好从一开始就将日志合并到微服务架构中。在许多情况下，这意味着微服务来自其它微服务收集日志数据创建的。然而，在其他情况下，每个服务可以开展自己的微测井，数据重定向到一个中心位置。
　　无论哪种战略目标应该是确保微服务架构有利于从整个应用程序的日志数据的收集，并把它的中心位置分析和存储。

结论

　　设计微服务时没有一个一成不变的规定。 然而，作为一般的指导方针，上述原则将帮助您规划一个微服务体系结构：提供微服务应该具有的所有好处，而不会遇到设计不当的微服务体系结构给开发人员和IT团队带来的麻烦。

更多产品了解

欢迎扫码加入云巴巴企业数字化交流服务群

产品交流、问题咨询、专业测评

都在这里！