什么是微服务架构

微服务的发展史

  在微服务到来之前,单体应用程序所暴露的缺点主要有:

  • 复杂性高
  • 扩展性差
  • 团队协作开发成本高
  • 部署效率低下
  • 系统很差的高可用性

  复杂性,体现在:随着业务的不断迭代,项目的代码量急剧的增多,项目模块也会随着而增加,整个项目就会变成的非常复杂。

  开发成本高,体现在:团队开发几十个人在修改代码,然后一起合并到同一地址分支,打包部署,测试阶段只要有一小块功能有问题,就得重新编译打包部署,重新测试,所有相关的开发人员都得参与其中,效率低下,开发成本极高。

  扩展性差,体现在:在新增功能业务的时候,代码层面会考虑在不影响现有的业务基础上编写代码,提高了代码的复杂性。

  部署效率低,体现在:当单体应用的代码越来越多,依赖的资源越来越多时,应用编译打包、部署测试一次,需要花费的时间越来越多,导致部署效率低下。

  高可用差,体现在:由于所有的业务功能最后都部署到同一个文件,一旦某一功能涉及的代码或者资源有问题,那就会影响到整个文件包部署的功能。举个特别鲜明的示例:上世纪八、九十年代,很多的黄页以及延伸到后来的网站中,很多的展示页面与获取数据的后端都是在一个服务模块中。这就造成一个很不好的影响:如果只是修改极小部分的页面展示或图片展示,则需要把整个服务模块进行打包部署,这样会导致时间的严重浪费以及成本的增加。更加糟糕的是,给用户带来非常不好的体验,用户无法理解的是:只是换个网站的某块微小的展示区,导致了整个网站在那一时刻无法正常的访问。当然,也许,对于那个时候互联网的不发达,人们对于这样的体验,已经算是一种幸福的享受了。

  由于单体应用具有以上的种种缺点,导致了一个新名词、新概念的诞生:微服务。

微服务到底是啥

  其实,从早年间的单体应用,到 2014 年起,得益于以 Docker 为代表的容器化技术的成熟以及 DevOps 文化的兴起,服务化的思想进一步演化,演变为今天我们所熟知的微服务。那么,微服务到底是啥?

  微服务,英文名:microservice,百度百科上将其定义为:SOA 架构的一种变体。微服务(或微服务架构)是一种将应用程序构造为一组低耦合的服务。

  微服务有着一些鲜明的特点:

  • 功能单一
  • 服务粒度小
  • 服务间独立性强
  • 服务间依赖性弱
  • 服务独立维护
  • 服务独立部署

  对于每一个微服务来说,其提供的功能应该是单一的;其粒度很小的;它只会提供某一业务功能涉及到的相关接口。如:电商系统中的订单系统、支付系统、产品系统等,每一个系统服务都只是做该系统独立的功能,不会涉及到不属于它的功能逻辑。

  微服务之间的依赖性应该是尽量弱的,这样带来的好处是:不会因为单一系统服务的宕机,而导致其它系统无法正常运行,从而影响用户的体验。同样以电商系统为例:用户将商品加入购物车后,提交订单,这时候去支付,发现无法支付,此时,可以将订单进入待支付状态,从而防止订单的丢失和用户体验的不友好。如果订单系统与支付系统的强依赖性,会导致订单系统一直在等待支付系统的回应,这样会导致用户的界面始终处于加载状态,从而导致用户无法进行任何操作。

  当出现某个微服务的功能需要升级,或某个功能需要修复 bug 时,只需要把当前的服务进行编译、部署即可,不需要一个个打包整个产品业务功能的巨多服务,独立维护、独立部署。

  上面描述的微服务,其实突出其鲜明特性:高内聚、低耦合,问题来了。什么是高内聚,什么是低耦合呢?所谓高内聚:就是说每个服务处于同一个网络或网域下,而且相对于外部,整个的是一个封闭的、安全的盒子。盒子对外的接口是不变的,盒子内部各模块之间的接口也是不变的,但是各模块内部的内容可以更改。模块只对外暴露最小限度的接口,避免强依赖关系。增删一个模块,应该只会影响有依赖关系的相关模块,无关的不应该受影响。

  所谓低耦合:从小的角度来看,就是要每个 Java 类之间的耦合性降低,多用接口,利用 Java 面向对象编程思想的封装、继承、多态,隐藏实现细节。从模块之间来讲,就是要每个模块之间的关系降低,减少冗余、重复、交叉的复杂度,模块功能划分尽可能单一。

微服务的革命性与重要性

  上一小节讲述了什么是微服务,微服务的鲜明特性。其实,从单体应用看微服务,就能看出微服务的重要性,它是彻底改革了应用程序的惯性,它的设计理念的出现:让开发人员减少大量的开发成本以及修复成本;让产品的使用者拥有一种舒适的体验感。它解决了单体应用程序的很多难以解决的问题,更具有创新性。它让我们的系统尽可能快地响应变化。

  微服务将原来耦合在一起的复杂业务拆分为单个服务,规避了原本复杂度无止境的积累,每一个微服务专注于单一功能,并通过定义良好的接口清晰表述服务边界。

  由于微服务具备独立的运行进程,所以每个微服务可以独立部署。当业务迭代时只需要发布相关服务的迭代即可,降低了测试的工作量同时也降低了服务发布的风险。

  在微服务架构下,当某一组件发生故障时,故障会被隔离在单个服务中。如通过限流、熔断等方式降低错误导致的危害,保障核心业务的正常运行。

上一篇:《SpringBoot揭秘:快速构建微服务体系》—第3章3.1节SpringBoot的工作机制


下一篇:通过禁用SSLv3修复POODLE漏洞