Spring Cloud学习笔记6—— 单块架构与微服务架构

什么是单块架构

功能代码和数据集中在一起，所有编译文件打成一个发布包，部署在同一个进程中，单块架构是所有大型系统演变的基础和前提。

单块架构的优缺点

优点

• 功能划分清楚
• 层次关系良好
• 每一层独立
• 部署简单
• 技术单一
• 用人成本低

缺点

• 功能仍然太大
• 升级风险高，需要升级一个服务时，不得不对整个系统做升级（整个系统一起打发布包）
• 维护成本增加
• 交付周期变长，必须全部完成才能打包交付
• 可伸缩性差，因为所有功能点都在同一个系统中，要扩展某一个功能点时必须把所有功能点也扩展
• 监控困难，不同功能点都在统同一进程中，而很多监控都只能细到进程级别，难以再细化

如何将单块架构转为微服务架构

SOA的出发点是将整个系统打散，成为不同的功能单元，每个单元称为服务，服务之间需要中立的、与平台无关的方式定义的接口，以跨越不同的硬件平台、操作系统平台、编程语言，使得构建在各式各样的系统中可以以一种统一、通用的方式进行交互。

现在将SOA进一步拆分，就成了微服务架构。

微服务是SOA的一种特例，比传统SOA的粒度更小。

微服务架构是什么

微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写。

微服务架构就是将一个完整的应用从数据存储开始垂直拆分成多个不同的服务，每个服务都能独立部署、独立维护、独立扩展，服务与服务间通过诸如RESTful API的方式互相调用。

微服务架构是用来开发应用的，这种应用会有很多小的服务来组成，这些服务都可以运行在自己的进程中，即可以实现独立部署，这些服务之间通过轻量级的通讯机制来进行交互，例如http的交互方式，这些服务之间并没有非常强的技术上的关联，可以采用不同的技术栈、使用不同的数据存储形式。

微服务架构的设计原则

• 拆分足够微，颗粒度太大的话无法发挥微服务的优势，颗粒度太细的话会导致服务数量太多引起服务管理问题
• 轻量级通信
• 领域驱动原则，要深刻地了解当前要开发的业务功能
• 单一职责原则
• DevOps及两个披萨，每个服务的团队应该小而精并且具备完全自治的全栈能力
• 不限于技术栈

如何来设计微服务系统

• 服务拆分
• 服务注册，微服务启动时将微服务信息注册到服务注册中心（或服务注册表）中，服务注册中心可以获取每个微服务的状态
• 服务发现，想调用另一个服务的功能时，去服务注册表中获取需要调用的服务的信息（如：接口、服务名称等），调用服务
• 服务消费，指调用其他服务
• 统一入口，只要知道入口的名称，不需要知道具体的某个服务的名称
• 配置管理
• 熔断机制
• 自动扩展

微服务的拆分的意义

• 易于实现
• 易于维护
• 易于部署
• 易于更新

正向的反馈闭环

整个速度会比传统开发快很多

拆分的方法

横向拆分

按照不同的业务功能拆分成不同的微服务

纵向拆分

把一个业务功能里面不同的模块或者组件进行拆分，例如把公共组件拆分成独立的基础设施下沉到底层，形成相对独立的基础设施层

使用DDD

DDD就是驱动设计原则来进行拆分。一个微服务应该能够反映出业务的领域模型，使用领域驱动设计不但可以减少微服务环境中通用语言的复杂性，而且还可以帮助团队弄清楚领域的边界、理清上下文的边界