微服务的发展史

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

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

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

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

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

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

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

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

微服务到底是啥

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

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

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

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

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

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

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

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

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

微服务的革命性与重要性

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

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

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

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