SpringCloud与Docker微服务架构实战读书笔记（一）

微服务架构概述

单体应用架构存在的问题

单体应用：一个归档包（例如war格式）包含所有功能的应用程序

优点：比较容易部署、测试

缺点：

• 复杂性高：一个应用百万行级别，修改代码容易牵一发而动全身
• 技术债务：已使用的系统设计或代码难以被修改
• 部署频率低：构建和部署的时间长→部署频率低→两次发布之间有大量功能变更与缺陷修复，出错概率比较高
• 可靠性差：某个应用bug，可能会导致整个应用的崩溃
• 扩展能力受限：单体应用智能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩
• 阻碍技术创新：引入新框架或新技术平台的成本非常高

如何解决单体应用架构存在的问题

微服务就是这样的一种架构模式。

什么是微服务

微服务架构应具备以下特性：

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

微服务架构的优点与挑战

微服务架构的优点

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

微服务架构面临的挑战

• 运维要求较高：更多的服务意味着更多的运维投入。
• 分布式固有的复杂性：使用微服务构建的是分布式系统。对于系统分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战
• 接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有使用了该接口的微服务都需要做调整。
• 重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这个功能，从而导致代码重复。尽管可以使用共享库来解决这个问题（例如可以将这个功能封装成公共组件，需要该功能的微服务引用该组件），但共享库在多语言环境下不一定行得通了。

微服务设计原则

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

• 服务自治原则：每个微服务应具备独立的业务能力、依赖于运行环境。在微服务架构中，服务是独立的业务单元，应该与其他服务高度解耦。每个微服务从开发、测试、构建、部署，都应当可以独立运行，而不应该依赖其他的服务。

• 轻量级通信机制：微服务之间应该通过轻量级的通信机制进行交互。轻量级的通信机制应具备两点：首先是它的体量较轻；其次是它应该是跨语言、跨平台的。例如我们所熟悉的REST协议，就是一个典型的“轻量级通信机制”。

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

• 微服务粒度：微服务的粒度是难点，也常常是争论的焦点。应当使用合理的粒度划分微服务，而不是一味地把服务做小。代码量的多少不能作为微服务划分的依据，因为不同的微服务本身的业务复杂性不同，代码量也不同。

  在微服务的设计阶段，就应该确定其边界。微服务之间应该相对独立并保持松耦合。

  领域驱动设计（Domain Driven Design，简称DDD）中的“界限上下文”可作为划分微服务边界、确定微服务粒度的重要依据。同时，在划分微服务的过程中，还应综合考虑团队的现状。

  每个架构师都应该研究下康威定律

  《领域驱动设计》

如何实现微服务架构

技术选型

相对单体应用的交付，微服务应用的交付要复杂很多，不仅需要开发框架的支持，还需要一些自动化的部署工具，以及IaaS、PaaS或CaaS的支持。

下面从开发和运行平台两个维度考虑挑选技术选型。

• 开发框架的选择

  可使用Spring Cloud作为微服务开发框架。

  首先，Spring Cloud具备开箱即用的生产特性，可大大提升开发效率；再者，SpringCloud的文档丰富、社区活跃，遇到问题比较容易获得支持；更为可贵的是，SpringCloud为微服务架构提供了完整的解决方案。

  当然，也可使用其他的开发框架或者解决方案来实现微服务，例如Dubbo、Dropwizard、Armada等。

• 运行平台

  微服务并不绑定运行平台，将微服务部署在PC Server，或者阿里云、AWS等云计算平台都是可以的。

架构图及常用组件

微服务开发框架-Spring Cloud

SpringCloud简介

尽管SpringCloud带有Cloud字样，但它并不是云计算解决方案，而是在SpringBoot基础上构建的，用于快速构建分布式系统的通用模式的工具集。

《十二要素应用宣言》、云原生应用

SpringCloud特点

• 约定优于配置
• 适用于各种环境。开发、部署在PC Server或各种云环境（例如阿里云、AWS等）均可。
• 隐藏了组件的复杂性，并提供声明式、无xml的配置方式。
• 开箱即用，快速启动。
• 轻量级的组件。SpringCloud整合的组件大多比较轻量。例如Eureka，Zuul，等等，都是各自领域轻量级的实现。
• 组件丰富，功能齐全。SpringCloud为微服务架构提供了非常完整的支持。例如，配置管理、服务发现、断路器、微服务网关等。
• 选型中立、丰富。例如，SpringCloud支持使用Eureka、ZooKeeper或Consul实现服务发现。
• 灵活。SpringCloud的组成部分是解耦的，开发人员可按需灵活挑选技术选型。