电脑
linux操作系统
在进行架构或技术选型时，将网络上找到的一些所谓的最佳实践文章作为指南，一旦做出了错误的决定，就要付出惨重的代价。如果能够避免犯下这种错误，那么写这篇文章都是值得的。
关于微服务的优势和劣势已经有过太多的讨论，不过我仍然看到很对它进行着“盲目崇拜”。冒着“重复发明轮子”的风险（Martin Fowler 已经写过“Microservice Premium”的文章），我想把我的一些想法写下来，在必要的时候可以发给客户，也希望能够帮助人们避免犯下我之前见过的那些错误。在进行架构或技术选型时，将网络上找到的一些所谓的最佳实践文章作为指南，一旦做出了错误的决定，就要付出惨重的代价。如果能够避免犯下这种错误，那么写这篇文章都是值得的。如今微服务是个热门技术，微服务架构一直以来都存在（面向服务架构也算是吧？），但对于我所来说，微服务不仅浪费了他们的时间，分散了他们的注意力，而且让事情变得更糟糕。
这听起来似乎很奇怪，因为大部分关于微服务的文章都会肯定微服务的各种好处，比如解耦系统、更好的伸缩性、移除开发团队之间的依赖，等等。有 Uber、Airbnb、Facebook 或 Twitter 那样的规模，那么就不存在什么问题。我曾经帮助一些大型组织转型到微服务架构，包括搭建消息系统和采用一些能够提升伸缩性的技术。不过，对来说，很少需要这些技术和微服务。
Russ Miles 在他的《让微服务失效的八种方式》这篇文章中表达了他的首要观点，而在我看来，这些场景却到处可见。总是的最佳实践，用它们来弥补自身的不足。但是，最佳实践是要视情况而定的。有些东西对于 Facebook 来说是最佳实践，但对于只有不来说，它们就不一定也是最佳实践。小一些，你仍然能够在一定程度上从微服务架构中获得好处。但是，对来说，大规模地迁移到微服务是一种过错，而且对技术人来说是不公平的。
为什么选择微服务？一般来说，采用微服务架构最主要的目的是要减少或者消除开发团队间的依赖，或者提升系统处理大流量负载的能力（比如伸缩性）。开发人员经常抱怨的问题和常见的症状包括合并冲突、由未完整实现的功能引起的部署错误以及伸缩性问题。接下来让我们逐个说明这些问题。
的早期阶段，开发团队规模不大，使用的技术也很简单。人们在一起工作，不会出现混乱，要实现一些功能也比较快。一切看起来都很美好。的不断发展，开发团队也在壮大，代码库也在增长，然后就出现了多个团队在同一个代码库上工作的情况。这些团队的大早期的员工。的早期员工一般都是初级开发人员，他们并没有意识到一个问题，那就是在团队规模增长和代码库增长的同时，沟通成本也会随之提升。对于缺乏经验的技术人员来说，他们倾向于通过技术问题来解决人的问题，并希望通过微服务来减少开发团队之间的依赖和耦合。
实际上，他们真正需要做的是通过有效的沟通来解决人的问题。有多个开发团队时，团队之间需要协调，团队成员需要知道每个人都在做什么，他们需要协作。在这样规模的企业里，软件开发其实具有了社交的性质。如果团队之间缺乏沟通或者缺乏信息分享，不管用不用微服务，一样会存在依赖问题，而就算使用了微服务，也仍然存在负面的技术问题。将代码模块化作为解决这个问题的技术方案，确实能够缓解软件开发固有的团队依赖问题，但团队间的沟通仍然要随着团队规模的增长而不断改进。切记不要混淆了解耦和分布式二者的含义。由模块和接口组成的单体可以帮助你达到解耦的目的，而且你也应该这么做。你没有必要把应用程序拆分成分布式的多个独立服务，在模块间定义清晰的接口也能达到解耦的目的。
部分功能实现微服务里需要用到功能标志（feature flag），微服务开发人员需要熟悉这种技术。特别是在进行快速开发（下面会深入讨论）的时候，你可能需要部署一些功能，这些功能在某些平台上还没有实现，或者前端已经完全实现，但后端还没有，等等。的发展，部署和运维系统变得越来越自动化和复杂，功能标志变得越来越重要。
水平伸缩通过部署同一个服务的多个实例来获得系统的伸缩性，这是微服务的优点之一。不过，大多数过早却在这些微服务背后使用了同一个存储系统。也就是说，这些服务具备了伸缩性，但整个应用并不具备伸缩性。如果你正打算使用这样的伸缩方式，那为什么不直接在负载均衡器后面部署多个单体实例呢？你可以以更简单的方式达到相同的目的。再者，水平伸缩应该被作为杀手锏来使用。你首先要关注的应该是如何提升应用程序的性能。一些简单的优化常常能带来数百倍的性能提升，这里也包括如何正确地使用其他服务。
理论理解