什么是微服务架构

这是我参与更文挑战的第23天，活动详情查看：更文挑战。

微服务的发展史

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

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

  复杂性，体如今：随着业务的不断迭代，项目的代码量急剧的增多，项目模块也会随着而增长，整个项目就会变成的很是复杂。

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

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

  部署效率低，体如今：当单体应用的代码愈来愈多，依赖的资源愈来愈多时，应用编译打包、部署测试一次，须要花费的时间愈来愈多，致使部署效率低下。

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

  因为单体应用具备以上的种种缺点，致使了一个新名词、新概念的诞生：微服务。

微服务究竟是啥

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

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

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

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

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

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

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

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

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

微服务的革命性与重要性

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

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

  因为微服务具有独立的运行进程，因此每一个微服务能够独立部署。当业务迭代时只须要发布相关服务的迭代便可，下降了测试的工做量同时也下降了服务发布的风险。

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