了解微服务

1、什么是微服务

      微服务是与之前的服务化思路和实践相比较而来的。早些年的服务实现和实施思路是将很多功能从开发到交付都打包成一个很大的服务单元（一般称为Monolith），而微服务实现和实施思路则更强调功能趋向单一，服务单元小型化和微型化。

      微服务就是要倡导大家尽量将功能进行拆分，将服务粒度做小，使之可以独立承担对外服务的职责，沿着这个思路开发和交付的软件服务实体就叫做“微服务”。

2、微服务因何而生

      对于Monolith服务来说，如果团队不大，软件复杂度不高，那么，使用Monolith的形式进行服务化治理是比较合适的，而且，这种方式对运维和各种基础设施的要求也不高。

      但是，随着软件系统的复杂度持续飙升，软件交付的效率要求更高，投入的人力以及各项资源越来越多，基于Monolith的服务化思路就开始“捉襟见肘”。

      在开发阶段，如果我们遵循Monolith的服务化理念，通常会将所有功能的实现都统一归到一个开发项目下，但随着功能的膨胀，这些功能一定会发给不同的研发人员进行开发，造成的后果就是，大家在提交代码的时候频繁冲突并需要解决这些冲突，单一的开发项目成为了开发期间所有人的工作瓶颈。

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

     到了软件交付阶段，如果我们遵循Monolith的服务化理念，那么，我们一定是将所有这些开发阶段并行开发的项目集合到一起进行交付。很显然，只要有一个功能项目未开发测试完成，服务就不能交付，这大大降低了服务的交付效率。如果每个功能项目可以各自独立交付，顺着这个思路，自然而然地，大家逐渐各自独立，每个功能或者少数相近的功能作为单一项目开发完成后将作为一个独立的服务单元进行交付，从而在服务交付阶段，大家也能够并行不挬，各自演化而不受影响。

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

3、微服务会带来哪些好处。

（1）独立

      我们说微服务打响的是各自的独立战争，所以，每一个微服务都是一个小王国，这些微服务跳出了“大一统（Monolith）”王国的统治，开始从各个层面打造自己的独立能力，从而保障自己的小王国可以持续稳固的运转。

      开发阶段的独立，保证了微服务的研发可以高效进行。

      在微服务治理体系下，各个微服务交付期间也是各自独立交付的，从而使得每个微服务从开发到交付整条链路上都是独立进行，这大大加快了微服务的迭代和交付效率。

      微服务交付之后需要部署运行，对微服务来说，它们运行期间也是各自独立的。

      微服务独立运行可以带来两个比较明显的好处。

      第一个就是可扩展性。我们可以快速地添加服务集群的实例，提升整个微服务集群的服务能力。

      第二个是隔离性。隔离性实际上是可扩展性的基础，当我们将每个微服务都隔离为独立的运行单元之后，如何一个或者多个微服务的失败都将只影响自己或者少量其他微服务，而不会大面积地波及整个微服务运行体系。

（2）多语言生态

      微服务独立之后，给了对应的团队和组织快速迭代和交付的能力，同时，也给团队和组织带来了更多的灵活性，实际上，对应交付不同微服务的团队或者组织来说，现在可以基于不同的计算机语言生态构建这些微服务。有一点需要注意：为了让服务的访问者可以用统一的接口访问所有这些用不同语言开发和交互的微服务，应该尽量统一微服务的服务接口和协议。

      在微服务的生态下，互通性应该是需要重点关注的因素，没有互通，不但服务的访问者和用户无法很好地使用这些微服务，微服务和微服务之间也无法相互信赖和帮助，这将大大损耗微服务研发体系带来的诸多好处，而多语言生态也会变成一种障碍和负累，而不是益处。

4、微服务会带来哪些挑战

      服务“微”化之后，一个显著的特点就是服务的数量增多了。而数量大这一特点则决定了，我们无法通过个性化的生产模式来支撑整个微服务的交付链路和研发体系，虽然微服务化之后，我们可以投入相应的人力和团队对应各个微服务的开发和交付，可扩展性上绝对没有问题，但这不意味着现实情况下我们就能这样做，因为这些都涉及人力和资源成本，而这往往是受限的。所以，使用标准化的思路来开发和交付微服务就变成了自然而然的选择。