尽管微服务是一个相对流行的新术语，但现在刚刚出现，但从本质上讲，微服务并不是一个新概念。

  实际上，许多SOA（面向服务的体系结构）实施成熟度公司已经在使用和实施微服务。 只是他们只是在默默地发财，不介意是否有一个更时髦的术语来清楚地表达SOA的这种发展趋势。

  微服务实际上是面向服务的思想的最佳实践方向。 遵循SOA概念，每个企业都长期处于面向服务的治理道路上，并且存在更多陷阱。 随着基础架构的成熟，微服务自然而然地诞生。

  当然，将其称为微服务的原因与以前的维修思想和实践进行了比较。

  早些年，服务实现和实现的思想是将从开发到交付的许多功能打包到一个大型服务单元（通常称为Monolith）中，而微服务实现和实现的思想则强调功能倾向于 单身，服务单位很小。 和小型化。

  如果我们以“茶壶煮饺子”作为类比，我们曾经在一个茶壶里煮很多饺子，但是现在（在微服务之后），我们基本上在一个茶壶里煮了一个饺子，这些饺子是服务的功能。 茶壶是一个包装并提供这些服务功能的服务单元。

因此，从思想和概念上讲，微服务是鼓励每个人尽可能地分离其功能，并使服务粒度更小，以便他们可以独立承担外部服务的责任。 按照这种思路开发和交付的软件服务实体称为“微服务”，作者称其为“微服务系统”，用于围绕该思想和概念构建的一系列基础结构和指导思想。

   

我们应该对微服务的概念有一个大致的了解，但是微服务是如何产生的呢？ 将许多功能包装到大型服务单元中进行交付的原始做法是否不满足需求？

  实际上，并不是说原始的“ Monolith”维修实践不能满足要求，也不是坏事，而是有其合理的情况。

  对于Monolith服务，如果团队不大且软件复杂性不高，则将Monolith用于面向服务的治理更合适，并且这种方法不需要高昂的运营和维护以及各种基础架构。  。

  但是，随着软件系统的复杂性不断提高，对软件交付的效率要求越来越高，并且投入了越来越多的人力和各种资源，基于Monolith的面向服务的思想已经开始“伸展”。

  在开发阶段，如果我们遵循Monolith的面向服务的概念，通常会将所有功能的实现归为一个开发项目。 但是，随着功能的扩展，这些功能将分配给不同的开发人员进行开发，其结果是，每个人在提交代码时都会经常发生冲突，需要解决这些冲突。 单个开发项目已成为开发过程中每个人的瓶颈。

  为了减轻这种困扰，我们将根据要开发的功能将项目自然地分为不同的项目，以便负责不同功能的研发人员可以在自己的代码项目上进行开发，从而解决了每个人都无法并行处理的问题。 发展阶段。 发展的困境。

  在软件交付阶段，如果我们遵循Monolith的服务理念，那么我们必须收集在这些开发阶段中并行开发的所有项目以进行交付。

  这涉及早期维修实践中众所周知的“火车模型”，即所交付的服务就像火车一样，并且与该服务有关的所有功能所对应的项目结果就是要装载到货物上的物品。 火车车厢。 只有在所有项目都经过开发和测试以完成整个服务的交付之后，才能加载和启动交付的火车。

  显然，只要有未准备好运送货物的车厢（即功能项目尚未开发和测试），火车就无法发送，服务也就无法交付，这大大降低了服务交付的效率 。 如果每个功能项都可以独立交付，那么就不必全部等同于一列火车了，单独出发就足够了。

  按照这种思路，自然地，每个人都逐渐变得独立。 每个功能或一些类似功能在作为单个项目开发后都将作为一个独立的服务单元交付，因此在服务交付阶段，每个人都可以并行发展。 不受影响。

  因此，随着服务和系统复杂性的逐步提高，为了能够在整个软件交付链路上有效扩展，自然而然地，将独立的功能和服务单元分开以形成微服务。

  这就像在打不同的战斗。 当双方人数较少且战场复杂度不高时，Monolith的统一指挥与调度方法是合适的。 一旦打了一场大仗（类似于系统复杂性的增加），双方肯定会投入大量的部队（软件研发团队的规模会不断扩大）。 如果它们仍在较小甚至固定的战场上作战，则显然无法使用它们！

      因此，小战有小战，大战有大战。 微服务实际上是帮助扩展组织能力和提高团队效率的一种方式。 它帮助我们从软件中学习，从开发到交付，再到团队和组织级别进行多维扩展。

  总的来说，一方面，微服务可以帮助我们应对不断增长的系统复杂性；另一方面， 另一方面，微服务可以帮助我们扩大范围，从开发阶段的项目并行开发扩展到交付阶段的并行交付扩展，然后扩展相应的组织结构和组织能力，所有这些 从微服务中受益。