第1章微服务架构概述

第一章 微服务架构概述(了解)

单体应用架构存在的问题

• 一个归档包(如war)包含所有功能的应用程序，通常称为单体应用。而架构单体应用的方法论，就是单体应用架构。

• 单体应用比较容易部署，测试，在项目的初期，单体应用可以很好地运行，但是随着需求地增加，代码库在飞速地膨胀，单体架构变得越来越臃肿，可维护性，灵活性逐渐降低，维护成本越来越高。
• 单体应用存在的问题
  • 复杂性高：整个项目包含的模块非常多，模块的边界模糊，依赖关系不清晰，代码质量参差不齐。
  • 技术债务：随着时间的推移，需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越级越多。“不修不坏”，这就非常常见。
  • 部署频率低：随着代码的增多，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。
  • 可靠性差：某个应用Bug，如：死循环，OOM等，可能会导致整个应用的崩溃。
  • 扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。
  • 阻碍技术创新：单体应用往往使用统一的技术平台或方案解决所有的问题。这就要求团队中的每一个人都必须使用相同的开发语言和框架。

什么是微服务

• 微服务是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。

微服务架构特性

• 每个微服务可独立运行在自己的进程里。
• 一系列独立运行的微服务共同构建起整个系统。
• 每个服务为独立的业务开发，一个微服务只关注某个特定的功能。如：订单管理，用户管理。
• 微服务直接通过一些轻量级的通信机制进行通信，如:RESTful API进行调用。
• 可以使用不同的语言与数据库存储技术。
• 全自动的部署机制。

使用微服务构建传统单体应用

• 将整个应用分解为多个微服务，各个微服务独立运行在自己的进程中，并分别有自己的数据库，微服务之间使用REST或者其他协议通信。

微服务架构的优点与挑战

微服务架构的优点

• 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以它业务清晰，代码量较少。
• 单个微服务启动较快：单一微服务代码量较少，所以启动会比较快。
• 局部修改容易部署：单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。
• 技术栈不受限：在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。如：某些服务可使用关系型数据库MySQL；某些微服务有图形计算地需求，可以使用Neo4j；甚至可根据需要，部分微服务使用Java，部分使用Node.js。
• 按需伸缩：可根据需求，实现细粒度的扩展。如：系统中的某个微服务遇到了瓶颈，可以结合这个微服务的业务特点，增加内存，升级CPU或者是增加节点。

微服务架构面临的挑战

• 运维要求较高：在单体架构中，只需要保证一个应用的正常运行，而在微服务中，需要保证几十甚至几百个服务的正常运行与协作，这给运维带来了挑战。
• 分布式固有的复杂性：对于一个分布式的系统，系统容错，网络延迟，分布式事务等都会带来巨大的挑战。
• 接口调整成本高：微服务之间通过解口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。
• 重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。

微服务设计原则

• 单一职责原则：单一职责原则指的是一个单元(类，方法或者服务等)只应关注整个系统功能中单独，有界限的一部分。单一职责原则可以帮助我们更优雅地开发，更敏捷地交付。

• 服务自治原则：服务自治是指每个微服务应具备独立的业务能力，依赖与运行环境。在微服务架构中，服务是独立的业务单元，应该与其他服务高度解耦。每个微服务都应该可以独立运行，不依赖其他的服务。

• 轻量级通信机制：微服务之间应该通过轻量级的通信机制进行交互。轻量级的通信机制应具备两点：

  • 它的体量较轻。
  • 它应该是跨语言，跨平台的。

  微服务架构中，常用的协议有REST,AMQP,STOMP,MQTT等。

• 微服务粒度：微服务的粒度是难点，应当使用合理的粒度划分微服务，而不是一味地把服务做小。微服务之间应相对独立并保持松耦合。