1、SpringBoot 微服务的诞生

一直想写点关于 SpringBoot 的文章，奈何水平有限不敢轻易下笔，只能对一些浅显的问题进行总结。今天无意中发现一本好书《SpringBoot 快速构建微服务体系》，王福强老师的著作。里面对 SpringBoot 进行了更为深层的解释，内容非常不错。

接下来我会借这本书写写关于 SpringBoot 的内容。也推荐大家去看原著，支持下王福强老师，毕竟写书这件事真是不容易！！

0、微服务(Micro Service)的盛行

最近几年微服务(Micro Service)的概念很流行，其中Java中最耀眼的当属 SpringBoot 。背靠 Spring 框架衍生出来的整个生态体系，无论从“出身”，还是社区的支撑上， SpringBoot 都是微服务框架选型的不二之选。

王福强老师认为 SpringBoot 并非单一 一个微服务框架的概念就可以将其概括，应当将其看作是一种最佳实践更为贴切：一种 Spring 框架及其社区对“约定大于配置”理念的最佳实践。

1、什么是微服务(Micro Service)

微服务(Micro Service) 流行于近几年，但是实际上好多大的企业已经在使用和实施微服务了。各个大企业在微服务化的道路上走得时间长了，踩坑多了，整个软件交付链路上各个环节的基础设施逐渐成熟，进而微服务就诞生了。

之所以称为微服务，是和之前的服务化思路和实践相比较而来的。因为早些年的服务实现和实施思路是瀑布式的，也就是将很多功能从开发到交付都打成一个很大的服务单元，而微服务实现和实施的思路则更强调功能趋于单一，服务单元小型化和微型化。

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

2、微服务(Micro Service) 因何而生

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

但是随着互联网的蓬勃发展，软件的复杂化飙升，软件交付的效率要求更高，随之投入的资源越来越多，传统的服务之路“捉襟见肘”。

首先开发阶段，将多个功能统一到一个项目下，但随着功能的膨胀，这些功能会有不同的研发人员开发，造成后果就是，大家提交代码时候频繁冲突，并为解决冲突付出精力，使得单一的开发项目成为了开发期间所有人的工作瓶颈。

这个时候可以按照微服务的理念对要开发的功能模块进行拆分，从而负责不同功能的研发人员就可以在自己的项目进行代码管理。

到了软件交付阶段，如果是以前的瀑布式开发，所有开发完成的项目会集中交付，只能等待所有的功能测试完成后，才能完成整个项目的交付。如果有其中一环掉链子，可怕程度难以想象。

但是按照微服务理念，我们前期按照功能将服务单元进行了拆分，各自独立，研发人员开发完成后可以将其作为独立的单元进行交付，从而使得所有研发人员能够并行，各自演化不受影响。

总体来说，微服务可以应对飙升的复杂度；也可以对相应的组织架构进行扩展。

3、微服务带来的好处

首先每个微服务都是独立的项目，而且相对于整个项目也是相对独立的，进而在开发阶段保证了其快速迭代，高效进行开发。

其次虽然微服务是独立开发的，但是交付的时候还是可以一起交付的(但是这不是微服务的做法)。微服务体系下，各个服务交付时间独立，从而使得每个微服务从开发到交付整条链路都是独立进行的，加快了微服务的迭代和交付效率。

微服务独立运行可以带来明显的好处：

①可扩展性：可以快速添加服务集群的实例，提升整个微服务集群的服务能力，传统模式下，为了提高服务能力，很多是必须强化和扩展单一节点的服务能力来达成，如果单节点服务能力已达极限，就得从软件到硬件整体进行重构。

早些年开发者遵循JavaEE开发规范开发的Web应用，都需要以 War 包的形式部署到 tomcat、jetty等web容器中运行，即使每个war包提供的都是独立的微服务，但是它们都是统一部署到一个web容器中的，所以扩展能力受限于web容器整体。所以大多数情况下，都是一个tomcat只部署一个war包，然后扩展和复制多个tomcat实例来扩展整个应用服务集群。

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

③多语言生态：微服务独立后，给了对应的团队何组织快速迭代和交付的能力。同事也带来了更多的灵活性，实际上不同的交付团队可以基于不同的计算机语言构建这些微服务。比如说可以使用 Java 、Go、python等进行开发何交付，但是应该尽量统一微服务的服务接口和协议。

4、微服务带来的挑战

服务的数量明显增多。虽然微服务化后可以快速迭代开发交付，扩展性上也没有问题。但是在快速迭代中，对开发人员的要求更高，要对自己的开发的程序要更加熟悉，因为往往一个服务只有一个开发人员，好的情况外加一个备份人员，但往往是备份人员是另外一个微服务的主开发人员(小编的项目组就是这样子的)。