一、什么是微服务

微服务(Microservice)是服务化思路的一种最佳实践方向,遵循SOA的思路,各个企业在服务化治理的道路上走的时间长了,踩的坑多了,整个软件交付链路上各个环节的基础设施逐渐成熟了,微服务自然而然就诞生了。

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

微服务架构学习笔记(一):重新认识微服务_java


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

二、微服务因何而生

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

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

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

三、微服务带来的好处

1、独立,独立,再独立

可以把每一个微服务都看做一个小的王国,开始从各个层面打造自己的独立能力,从而保障自己的小王国可以持续稳固的运转。

首先,从开发层面来看,每一个微服务基本上都是各自独立的项目(project),而对应各自独立项目的研发团队基本上也是独立对应,这样的结构保证了微服务的并行研发,并且各自快速迭代,不会因为所有研发都投入一个近乎单点的项目,从而造成开发阶段的瓶颈。开发阶段的独立,保证了微服务的研发可以高效运行。简而言之,就是开发的时候各自进行,交付的时候也可以独立交付,从而使得每个微服务从开发到交付整条链路上都是独立进行,大大加快产品的迭代和交付效率。
微服务交付之后需要部署运行,对微服务来说,它们运行期间也是各自独立的(独立运行的好处:第一个就是可扩展性。可以快速的添加服务集群的实力,提升整个微服务集群的服务能力,而在传统的Monolith模式下,为了能够提升服务能力,必须强化和扩展单一节点的服务能力来达成。如果扩展到极限的话就要从软件到硬件整体进行重构了)。

对于Java开发者来说,Web应用都需要以WAR包的形式部署到tomcat、jetty等web容器中运行,即使每个war包提供的都是独立的微服务,但他们都是统一部署在一个web容器中,所以扩展能力受限于web容器作为一个进程的现状,无论如何调整web容器内部实现的线程设置还是会受限于web容器整体的扩展能力,所以现在大家都是一个web容器部署一个war,然后通过复制和扩展多个容器实例来扩展整个应用服务集群。

一个web容器中只部署一个war包的做法带给我们第二个好处,即隔离性。当我们将每个微服务都隔离为独立的运行单元后任何一个或多个微服务的失败都将只影响自己或者少量其他微服务,而不会大面积的波及整个服务运行体系(架构设计上交隔板模式)。

2、多语言生态

微服务既可以使用Java或Go等静态语言完成微服务的开发和交付也可以使用Python或Ruby等动态语言完成微服务的开发和交付,对于团队内部拥有多语言的组织奶说,可以最大化的发挥团队和组织内部各成员的优势(一定要统一微服务的服务接口和协议)。

微服务架构学习笔记(一):重新认识微服务_java_02


微服务带来的挑战

服务“微”化之后,最显著的特点就是服务的数量增多了,而数量大的这一特点则决定了我们无法通过个性化的生产模式来支撑整个微服务的交付链路和研发体系,这些都涉及人力和资源成本,往往这些都是受限的。