查看“微服务简介”的源代码

https://www.bilibili.com/video/BV1eU4y187zE

=== 什么是微服务 ===
微服务（MicroService）的概念最早是在 2014 年 Martin Fowler 和 James Lewis 共同提出，他们定义了微服务是由单一应用程序构成的小服务，

拥有自己的进程与轻量化处理，服务<u>依业务功能设计（微服务一个业务一个项目）</u>，以全自动方式部署，与其他服务使用 HTTP API 通讯（每个项目都是一个标准的 Web 项目，不再像之前 RPC 项目分为 provider 和 consumer）。

同时，服务会使用小规模集中管理（例如 Docker）技术，服务可以用不同的编程语言与数据库等。

提出的核心点：

# 微服务是架构，发展到现在微服务已经可以说是综合平台（架构以外还包含服务治理、注册中心、服务容灾等相关特性）
# 微服务中项目都称为服务
# 微服务拆分颗粒度为业务
# 微服务中服务和服务之间使用 HTTP 协议通信
# 微服务和 Docker 结合使用更方便
# 微服务是分布式架构的一种






=== 为什么使用微服务 ===
https://www.bilibili.com/video/BV1eU4y187zE/?p=2

==== 单体应用特点 ====
大部分的开发者都开发过单体应用，无论是传统的 Servlet+JSP，还是 SSM，还是现在的 SpringBoot，它们都是单体应用，那么长期陪伴我们的单体应用有什么弊端？

我们是面临了什么问题，导致我们要抛弃单体应用转向微服务架构呢？主要原因如下：

# 部署成本高（无论是修改 1 行代码，还是 10 行代码，都要全量替换）。
# 改动影响大，风险高（不论代码改动多少，成本都相同）
# 因为成本高，风险高，所以导致部署频率低（无法快速交付客户需求）
# 无法满足快速扩容，弹性伸缩，无法适应云环境特性等问题。

注意：<u>单体应用虽然有上面缺点，但是依然有自己的市场，如果项目规模比较小，办公类等不需要频繁修改版本的应用使用单体架构还是很方便的</u>。


==== 微服务特点 ====
微服务架构的特点：

* 针对特定服务发布，影响小，风险小，成本低；
* 频繁发布版本，快速交付需求；
* 低成本扩容，弹性伸缩，适应云环境等特点。

<u>微服务架构与现在企业中敏捷开发思想是匹配的，核心都是强调希望项目快速更新迭代（当项目需要快速更新迭代时微服务架构就特别合适）（这就是为什么使用微服务）</u>

我们知道一个朴素的理念，没有任何事物是完美的，任何东西都有两面性，有得必有失，那么在选择微服务在解决了快速响应和弹性伸缩的问题同时，它又给我们带来了什么问题？

简单总结如下（微服务架构的缺点）：

* 分布式系统的复杂性
* 部署，测试和监控的成本问题
* 分布式事务和 CAP 的相关问题
* 分布式中微服务架构相对于单体架构还需要处理很多事情。例如：分布式事务、团队合作等问题都需要明确的提前设计好。