设计微服务架构时应避免的五个错误

  【译】到目前为止，大多数研发人员已听说了微服务的种种好处。不过，真正通过将现有应用程序转换成微服务架构以“迁移整体式系统”时，你很有可能会发现设计有效的微服务架构困难重重。开发社区费了大量的时间讨论为何采用微服务架构，而不是讨论如何设计。

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

  让大多数研发人员描述有效的微服务架构，他们会告诉你应用程序每方面的功能都应该由不同的微服务提供支持。以支付应用程序为例，身份验证应由一个微服务处理，另一个微服务进行支付处理，另一个微服务运行前端，另一个存储和检索数据，依此类推。

  旨在将各大应用功能派给不同的微服务通常是个好主意。但是这个原则很容易过犹不及，往往会阻碍设计有效的微服务架构。

  有时，区别一项功能与另一项功能的界线很模糊。比如说，你是否应该将用户注册视作与用户身份验证不同的功能，因此为各自创建单独的微服务?如果你的应用程序将数据存储在多个位置，每个位置都应该有自己的微服务吗?还是该只有一个数据服务来处理所有位置?

  这些问题的答案是，这可能无关紧要。要弄清楚某应用程序将有多少微服务、各自处理哪些功能。如果你花太多的时间弄清楚如何在应用程序中拆分不同的任务，工作效率就不会很高。

  同样，设计微服务架构使每个微服务过小，因此就需要众多微服务来组成整个应用程序是常见的错误。

  开发人员之所以遇到这个陷阱，是因他们认为微服务越小越好。从某一种意义上说是对的将大型应用程序分成较小的离散单元是为应用程序提高可扩展性和可靠性的一种方法。

  但是如果微服务变得过小，以后开发和部署微服务时开销会大幅度提升。每个微服务需要各自的开发和部署管道(更加不用说单独的监控、日志和安全操作了)。

  因此，虽然你确实希望微服务小点，但不应该过小，也不应该让应用程序含有太多的微服务。作为一条普遍的准则，如果你的应用程序由不止十几个微服务组成，每个微服务可能太小，你应该将一些微服务合并起来，以不同的方式来设计架构。

  如今的常见做法是通过容器来部署微服务通常借助OpenShift或另一种基于Kubernetes的编排平台。

  但几年后还会是这样吗?不好说。部署技术日新月异，很难知道哪种部署解决方案将来对你的微服务应用最合理。

  因此，以需要特定类型部署技术的方式设计微服务架构是错误的。你不应该让自己依赖Kubernetes、甚至普通的容器才能部署应用程序，而是应设计一种可以在各种基础架构上、还可以在各种操作系统上运行的架构。

  你有时在微服务架构中看到的一个错误是要求：如果更新应用程序中的一个微服务，同时也要更新(或至少重新再启动)其他微服务。

  如果从整体式系统的角度来看，这种想法很自然。但是就微服务而言，这种方法意味着你是自找麻烦。微服务的目的一种原因是在不影响别的部分的情况下，更新、扩展或重新再启动应用程序的某些部分。

  因此，如果更改一个微服务的状态意味着也要更改其他微服务的状态，你就失去了微服务本该带来的许多灵活性。也更难搞持续交付，因为你无法在不影响其他服务的情况下推送针对某一服务的更新。

  另一方面，你的微服务不应太紧密地耦合在一起。设计架构时尽可能避免这种情况：如果依赖的另一个微服务没在运行，某一微服务就无法运行。

  很容易犯这个错误。你会认为能在以后为每个微服务编写代码时搞清楚日志，或者只要将日志代理部署到微服务环境中，它就能收集所需的所有数据。

  最好一开始就将日志纳入到微服务架构中。在许多情况下，这在某种程度上预示着专门创建一个微服务，用于从其他微服务收集日志数据。不过在其他情况下，每个微服务可能会进行自己的日志记录，将数据重定向到中心位置。

  无论采用哪种策略，目的都应该是确保微服务架构便于从整个应用程序收集日志数据，并将其放入到中心位置以便分析和保存。

  设计微服务时没有一成不变的规定。不过作为一般准则，上述原则仍将帮助你规划好这样的微服务架构：提供微服务本应提供的所有好处，又没有因糟糕设计的微服务架构给研发人员和IT团队带来的麻烦。