SpringCloud系列：2. SpringCloud生态详解以及涉及的技术栈

前言

1. SpringCloud的诞生以及市面上常见SpringCloud生态
2. Spring Cloud 生态中包含的技术详解
3. 微服务及微服务架构
   3.1 微服务
   3.2 微服务架构
4. 微服务的优点及其缺点
   4.1 微服务优点
   4.2 微服务缺点
5. 微服务涉及的技术栈
6. 为什么选择SpringCloud作为微服务架构

---

前言

1. 本章主要讲解：Spring Cloud 生态涉及的技术栈

1. SpringCloud的诞生以及市面上常见SpringCloud生态

1. 对于模块化拆分后出现的4个核心问题-->
    问题1：服务非常多，客户端如何访问？
    问题2：服务非常多，服务之间如何通信(基于Http或Rpc)？
    问题3：服务非常多，服务如何治理(注册中心)？
    问题4：服务非常多，某一个服务挂了怎么办？
-->从而衍生出了一套解决方案：Springcloud。
2. SpringCloud的诞生就是为了做分布式，通过分布式来解决上面出现
的4个问题。

3. SpringCloud不是一个技术，它是一个生态，就是很多东西集合在一
起的。同时SpringCloud是基于SpringBoot。


--------------------------------------------------


4. 市面上常见的SpringCloud 生态，来解决上面4个问题的解决方案，有如下几种↓
⑴ Spring Cloud NetFlix
- 一站式解决方案(上面问题都能够解决)。
⑵ Apache Dubbbo Zookeeper
- 半自动(上面4个问题只能解决其中几个)。
⑶ Spring Cloud Alibaba
- 全新的一站式解决方案。
 

2. Spring Cloud 生态中包含的技术详解

1. 再啰嗦一下：由于SpringCloud就是很多东西集合在一起的，里面包
含的东西(技术)就是为了解决上面这4个问题。

-------------------------------------------------

2. 对微服务的四个问题的简单梳理
⑴ 访问用到：Api网关  -->路由问题
⑵ 通信用到：Http或RPC  -->通信问题
⑶ 服务注册和发现用到：就是利用了高可用机制  -->高可用问题
⑷ 服务挂机用到：熔断机制  -->某个服务出问题，防止服务血崩
(比如A调用服务B,服务B调用服务C…如果C因为某些原因挂掉了,或者
网络原因掉不到C,这时候B这个方法也挂掉了,A这边也跟着挂….这就
是雪崩效应)

3. 总归一句话就是因为"网络不可靠"-->才会出现上面这四个问题。
- 所以正是因为分布式网络是不可靠的，才会造成"丢包，丢帧，数据
被拦截，数据丢失.."由此衍生出以上四个问题。

3. 微服务及微服务架构

3.1 微服务

1. 微服务详解
⑴ 微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个
的服务，彻底地去耦合每一个微服务提供单个业务功能的服务。
一个服务只做一件事情， 从技术角度看就是一种小而独立的处理过程，
类似进程的概念。

**每一个服务均能够自行单独启动或销毁，拥有自己独立的数据库**。
(每一个服务能够自行启动项目，是一个独立的功能模块)

⑵ 微服务：将单一服务划分成多个小服务==》简称"模块化"。
⑶ 划分出来的每一个小服务都有一个独立的端口，相当于每一个服务都
是一个进程，而不是一个线程。

⑷ "微服务"强调的是服务的大小，他关注的是某一个点,是具体解决某一
个问题/提供落地对应服务的一个服务应用， 狭义的看,可以看做是IDEA
中的一个个微服务工程,或者Moudel （即：一个模块，一个端口，就对应
了一个微服务）。

⑸ IDEA 工具里面使用Maven开发的一个个独立的小Moudle,它具体是使
用springboot开发的一个小模块，一个模块就做着一件事情


---------------------------------------------------


2. 微服务理解总结
⑴ 微服务要给用户提供真正的服务，他就需要将很多服务组合起来，
组合起来才变成一个真正的服务，就类似一条最简单的生产线。
⑵ 就像通过淘宝买商品(其中包含：订单模块-->交易模块-->支付
模块--->物流模块-->评论模块)

⑶ 单一的一个"订单模块"它根本不能称为一个真正的服务，单单一
个"交易"它也根本不叫一个真正的服务，你将其中一个模块拆分出来，
它根本没有任何作用，只是说可以简单运行起来而已，你只有将所有一
个个服务完整的拼接在一块，它才可以给用户提供一个完整的服务(缺
一不可)。
⑷ 每一个服务都是分开的，在开发或部署阶段都是独立的(交易模块
分开，支付模块分开...)。

3.2 微服务架构

1. 微服务架构是一种新的"架构形式"，它提倡将单一应用程序划分
成一组小的服务，服务之间互相协调，互相配合，为用户提供最终价
值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通
信机制互相协作,每个服务都围绕着具体的业务进行构建，并且能够
被独立的部署到生产环境中。

2. 在微服务架构的构建过程中，应尽量避免统一的, 集中式的服
务管理机制，对具体的一个服务而言,应根据业务上下文,选择合适
的语言，工具对其进行构建。

4. 微服务的优点及其缺点

4.1 微服务优点

1. 微服务的优点↓：
⑴ 每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定
的业务功能或业务需求。

⑵ 开发简单，开发效率提高，一个服务可能就是专一的只干一件事。

⑶ 微服务能够被小团队单独开发，这个小团队是2-5人的开发人员
组成。
⑷ 微服务是松耦合的。是有功能意义的服务。无论是在开发阶段或
部署阶段都是独立的。

⑸ 微服务能使用不同的语言开发。
⑹ 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署,
通过持续集成工具，如jenkins，Hudson，bamboo

⑺ 微服务易于被一个开发人员理解，修改和维护，这样小团队能够
更关注自己的工作成果。无需通过合作才能体现价值。

⑻ 微服务允许你利用融合最新技术。
⑼ 微服务只是业务逻辑的代码，不会和HTML，CSS 或其他界面混合。
⑽ 每个微服务都有自己的存储能力，可以有自己的数据库，也可以
有统一数据库。

4.2 微服务缺点

1. 微服务缺点↓：
⑴ 开发人员要处理分布式系统的复杂性。
⑵ 多服务运维难度,随着服务的增加，运维的压力也在增大。
⑶ 系统部署依赖。
⑷ 服务间通信成本。
⑸ 数据一致性
⑹ 系统集成测试。
⑺ 性能监控...

5. 微服务涉及的技术栈

1. 微服务涉及的技术栈，如图所示-“图-ms2”。
   ⑴ 在微服务技术栈中只列举了微服务其中一部分的内容，微服务的官网Spring Cloud中还包含了非常多的技术，具体可自行去了解。

图-ms2

6. 为什么选择SpringCloud作为微服务架构

整体解决方案和框架成熟度和社区热度高，可维护性好。
----->其他对于Springcloud更详细的资料可以去官网自行了解。