SpringCloud学习笔记01-初识微服务

---

前言

微服务架构是当前软件开发领域的技术热点。与之对应的是我们传统的单体应用架构。单体应用即一个归档包包含所有的应用程序，而架构单体应用的方法论就是单体应用架构。

单体应用存在的问题：

1. 复杂性高
2. 技术债务
3. 部署频率低
4. 可靠性差
5. 扩展能力差
6. 阻碍技术创新

---

提示：以下是本篇文章正文内容

一、微服务是什么？

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

二、微服务架构优缺点

1. 优点

• 易于开发和维护
• 单个微服务启动较快
• 局部修改，易部署
• 技术栈不受限
• 按需伸缩

2. 缺点

• 运维要求高
• 分布式固有的复杂性（系统容错、网络延迟、分布式事务等）
• 接口调整成本较高
• 重复劳动

---

三、微服务设计原则

1. 单一职责原则

单一职责可以帮助开发人员更优雅地开发、更敏捷地交付。

单一职责原则指的是一个单元（方法、类或者服务等）只应关注整个系统功能中单独、有界限的一部分。

2. 服务自治原则

微服务架构中，服务是独立的业务单元，应该与其他服务高度解耦。每个微服务从开发、测试、构建、部署都应独立运行。

服务自治是指每个微服务应具备独立的业务能力、依赖与运行环境。

3. 轻量级通信机制

微服务架构中各服务间应该通过轻量级的、跨平台的通信机制进行交互。例如Java的RMI协议不大符合要求，因为它绑定了Java语言

常用协议有：REST、AMQP、STOMP、MQTT等

4. 微服务粒度

应当使用合理的粒度划分微服务，不是一味地把服务做小。

微服务设计阶段就应该确定边界。

总结

这里对文章进行总结：

以上就是初步对微服务有了一个认识，微服务之间应相对独立并保持松耦合。《SpringCloud与Docker微服务架构实战》一书中作者提到了领域驱动设计（DDD）可以作为划分微服务边界、确定微服务粒度地重要依据，感兴趣的小伙伴可以自行学习。