微服务产生的前景

 ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------

     微服务的概念我们应该大体了解了，那么微服务又是怎么来的？原来将很多功能打包为一个很大的服务单元进行交付的做法不能满足需求吗？ 实际上，并非原来“大一统”（Monolith）的服务化实践不能满足要求，也不是不好，只是，它有自己存在的合理场景。对于Monolith服务来说，如果团队不大，软件复杂度不高，那么，使用Monolith的形式进行服务化治理是比较合适的，而且，这种方式对运维和各种基础设施的要求也不高。

       但是，随着软件系统的复杂度持续飙升，软件交付的效率要求更高，投入的人力以及各项资源越来越多，基于Monolith的服务化思路就开始“捉襟见肘”。 在开发阶段，如果我们遵循Monolith的服务化理念，通常会将所有功能的实现都统一归到一个开发项目下，但随着功能的膨胀，这些功能一定会分发给不同的研发人员进行开发，造成的后果就是，大家在提交代码的时候频繁冲突并需要解决这些冲突，单一的开发项目成为了开发期间所有人的工作瓶颈。

       为了减轻这种苦恼，我们自然会将项目按照要开发的功能拆分为不同的项目，从而负责不同功能的研发人员就可以在自己的代码项目上进行开发，从而解决了大家无法在开发阶段并行开发的苦恼。

      到了软件交付阶段，如果我们遵循Monolith的服务化理念，那么，我们一定是将所有这些开发阶段并行开发的项目集合到一起进行交付，这就涉及服务化早期实践中比较有名的“火车模型”，即交付的服务就像一辆火车，而这个服务相关的所有功能对应的项目成果，就是要装上火车车厢的一件件货物，交付的列车只有等到所有项目都开发测试完成后才可以装车出发，完成整个服务的交付。很显然，只要有一个车厢没有准备好货物（即功能项目未开发测试完成），火车就不能发车，服务就不能交付，这大大降低了服务的交付效率。如果每个功能项目可以各自独立交付，那么就不需要都等同一辆火车，各自出发就可以了。顺着这个思路，自然而然地，大家逐渐各自独立，每一个功能或者少数相近的功能作为单一项目开发完成后将作为一个独立的服务单元进行交付，从而在服务交付阶段，大家也能够并行不悖，各自演化而不受影响。

       所以，随着服务和系统的复杂度逐渐飙升，为了能够在整个软件的交付链路上高效扩展，将独立的功能和服务单元进行拆分，从而形成一个一个的微服务是自然而然发生的事情。这就像打不同的战役一样，在双方兵力不多、战场复杂度不高的情下，Monolith的统一指挥调度方式是合适的；而一旦要打大的战役（类似于系统复杂度提升），双方一定会投入大量的兵力（软件研发团队的规模增长），如果还是在狭小甚至固定的战场上进行厮杀，显然施展不开！所以，小战役有小战役的打法，大战役有大战役的战法，而微服务实际上就是一种帮助扩展组织能力、提升团队效率的应对“大战役”的方法，它帮助我们从软件开发到交付，进而到团队和组织层面多方位进行扩展。

       总的来说，一方面微服务可以帮助我们应对飙升的系统复杂度；另一个方面，微服务可以帮助我们进行更大范围的扩展，从开发阶段项目并行开发的扩展，到交付阶段并行交付的扩展，再到相应的组织结构和组织能力的扩展，皆因微服务而受惠。

以上解释参考    王福强著的《SpringBoot揭秘：快速构建微服务体系》
----------------------------------- ----------------------------------------------------------------------------------------------------------------------------------------

SOA与微服务（MicroService）

      SOA架构：

      针对的是一个企业级的所有单元服务的总线，将紧耦合的系统，划分为面向业务、粗粒度、松耦合、无状态的服务，服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统，但是其业务系统并没有彻底的组件化，服务化。

      SOA个人理解：

       在软件开发过程中，难以避免某项功能模块的更新升级，这就容易引起对其他服务的影响，有种牵一发而动全身的感觉；或者某个服务出现问题，可能会直接导致系统的崩溃。

       另外，对单个服务器，整个系统内容运行在同一个进程上，比如系统中就只有“宝贝搜索功能“和“购物车管理“两个服务接口，同时很多人访问，但是人与人的需求肯定是不同的，如果“宝贝搜索“与“购物车管理“是在同一进程上，那访问“宝贝搜索“和访问“购物车管理“的用户，其实都是对一个系统产生了访问压力。

     微服务架构：

       传统的SOA的问题引发了微服务架构的出现，将所有服务单元拆分，采用一组服务单元甚至单一服务单元的方式构建一个应用。并且独立部署在不同的进程中，可独立运行，服务之间定义了明确的边界，甚至不同的服务采用了不同的编程语言来实现，由独立的团队来维护。

       简单的来说，将整个系统的各个服务单元，拆分成了独立可运行，运行在不同进程上的微型服务系统。

     微服务个人理解：

    这样做的好处就是，首先问题可以细化，出现问题即可锁定服务单元，比如“宝贝搜索“功能不行了，那直接就找到宝贝搜索的那个微服务模块，进行排查，其他的服务模块并不影响运行。具有独立、可扩展性

    针对不同访问用户的需求可以跳转到不同的微服务进程上，这样直接减轻了单一系统那种压力，另外，可以针对性的对某项服务模块进行减压，比如“宝贝搜索”功能明显访问量大，那就给“宝贝搜索”功能的微服务多加几台服务器，构成一个小的集群，这样从某些方面来说，也是降低了开发成本。

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------

       微服务是与之前的服务化思路和实践相比较而来的。早些年的服务实现和实施思路是将很多功能从开发到交付都打包成了一个很大的服务单元，而微服务实现和实施思路则更强调功能趋向单一，服务单元小型化和微型化。如果用“茶壶煮饺子”来打比方的话，原来我们是在一个茶壶里煮很多个饺子，现在（微服务化后）则基本上是在一个茶壶煮一个饺子，而这些饺子就是服务的功能，茶壶则是将这些服务功能打包交付的服务单元。

       所以，从思路和理念上来讲，微服务就是要倡导大家尽量将功能进行拆分，将服务粒度做小，使之可以独立承担对外服务的职责，沿着这个思路开发和交付的软件服务实体就叫作“微服务”，而围绕着这个思路和理念构建的一系列基础
设施和指导思想，笔者将它称为“微服务体系”。

以上解释参考    王福强著的《SpringBoot揭秘：快速构建微服务体系》

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------