springCloud组件专题（开篇） --- 什么是springCloud

一、前言：

        开一个坑，从0开始搭建一个springCloud后端项目，并利用SpringSecurity-Oauth2完成单点登录，简单的实现一下RBAC。内容计划每周更新，有兴趣的同学可以先收藏一下本篇。

二、springCloud是什么

1.什么是微服务

java-web应用的进化大致可以分为几步：

        单体架构：我们的代码部署在一台服务器中，用户的访问也全都访问这一台服务器。一般只有一些访问量小，业务体量也好的项目才会采用这种架构，最多见的是一些内网项目会使用这种架构。

        集群架构：微服务流行之前，大多数公司都是以这种架构在部署服务。其实现方式就是，一份项目代码，在多台服务器上部署，然后通过nginx进行访问，由nginx来进行负载均衡。对比单体架构，集群架构具备了一定高可用的特性(就是某一个服务器挂了，不会导致整个服务无法使用)。这种架构对比单体架构，就多了很多的技术难题，比如：

        session共享：比如，用户A的第一次请求被nginx分配到了 S1服务器，但是第二次被分配到了S2服务器，S2服务器如何得到用户的seesion。

        数据库数据共享：集群服务是将一份代码多个节点部署，所以一个集群下的多个节点都是同一个数据库，但是对一些大型的项目来说，每个区域都有自己的一套数据（比如，西安地区的数据，咸阳地区的数据，分别放在两个不同的数据库中），所以数据共享就有很大的问题。当时很多项目经常在不同地区之间数据无法互通就有这个原因在。

        微服务架构：微服务架构是集群架构进一步进化的产物，简答来说，微服务就是将一个大的项目代码拆分成很多个能够独立启动的小项目，然后每一个小项目再以集群的方式部署。对比集群架构，它具有很多明显的优势，比如：每一个服务体量更小，启动更快；更便于拓展，每一个服务也好，整个项目也好，都更方便做横向的拓展，且对原本的业务侵入小；整个服务的健壮性更强，就算某一块小服务的节点完全不可用，其他服务也可以继续提供服务。至于集群架构时困扰开发者的两个问题，1.session共享,到了微服务时代直接玩无状态的token了，这问题直接回避。2。数据共享，由于微服务并不是一份代码部署，所以每个区域可以通过配置文件的修改独立访问自己的库，然后区域服务拥有不同服务名，上层服务调用时候直接路由到对应区域服务就好了。但是，微服务架构也带来了很多的技术问题，比如：

        1)每一个服务都是集群部署，服务之间如何寻址，如何调用

        2)极多的服务，开发者如何管理

        3)不同的服务之间，如何进行事务管理

        ......

2.什么是SpringCloud

        我们知道springCloud是解决微服务架构问题的技术，我们也知道了微服务是多套代码部署在一个或多个服务器上后产生的一种架构。所以，可以明白一件事情，SpringCloud绝对不是一个开箱即用的脚手架，不同于我们熟悉的SpringBoot，mybatis这些技术。SpringCloud是一整套工具的整合，从maven的层面来看，它是一个dependencyManagement下的条目，是一个管理包；从代码上讲，SpringCloud是一种解决问题的方案，而不是像nacos，feign，这种，一个具体的解决微服务问题的技术。

三、springCloud-alibaba又是什么

        我们了解了SpringCloud是一套解决方案，那么现在常说的springCloud-alibaba又是什么？

        从抽象逻辑来说，SpringCloud是一种理念，对这套理念，有两种实现方式，分别是netflix, alibaba。举一个具体例子，SpringCloud提出要有注册中心，netflix实现了一个注册中心叫做Eruka，而alibaba实现了一个注册中心叫Nacos。

        从具体代码层面来讲，SpringCloud和springCloud-alibaba都是dependencyManagement的条目（二、springCloud是什么 ---> 2.什么是SpringCloud 中那张截图可以看到）；

但是他们管理了不同的包，且目前来说，SpringCloud这个dependencyManagement条目默认是引入了netflix。

        从项目中点击maven的以来，进去看springCloud和springCloud-alibaba,如下图。可以发现，nacos，sentinel这些的管理在alibaba下，openfeign的管理在springCloud下。

总结：springCloud-alibaba是基于springcloud的一套微服务解决方案，它在springcloud的基础上增加了几个组件

四、springCloud-alibaba包含哪些常用组件，功能又是什么

1.注册中心，配置中心 nacos

2.网关gateWay

3.服务间调用 feign

4.流量控制组件 sentinal

5.分布式事务组件seata

6.消息队列RocketMQ

一个最简单的微服务架构图，一起理解一下，微服务中，请求是如何进行转发的：

服务在注册中心Nacos中进行注册；gateWay网关服务从注册中心获取已注册服务的列表；请求统一由GateWay服务处理，然后GateWay将请求转发给对应的业务服务；这就是一个最简单的微服务请求流转过程。在实际项目中，可能还会涉及到流控组件sentinal，链路跟踪组件skywalking等，他们的工作原理其实也是在这个最核心的请求流转过程中做了操作，本文不展开说，后面的更新到每一个组件时候会详细说。

五、关于springCloud的一些闲聊

        我在15年开始做开发，在某不能说名字的大厂就职，当时的项目是ssh(Spring+Struts2+Hibernate)框架，项目业务体量很大，项目启动一次需要大约6-7分钟，后来微服务开始流行，我们这个项目也开始微服务改造，最终项目拆成了许多个小项目。从开发者的角度来看，每个人只需要本地拉自己的几个服务就好，启动速度，调试成本都小了很多，而且接触微服务，也学到了一系列的新技术，从技术提升角度讲，也有不小的收获。

        后来去了一家小公司，业务体量并不大，并且还是要在客户内网部署。但是架构师在技术选型的时候依旧选择了springCloud-alibaba全系列，理由是方便扩展，用户的二次开发需求也能快速加进去。但是由于项目业务的特殊性（也和服务拆分粒度控制不够好有关），经常出现两个服务之间要传递大量数据的场景，并且出现了必须强一致性的分布式事务问题，这些都导致在后期开发过程中非常痛苦。而且从客户现场的本公司运维人员反馈，微服务架构对他们也是很大的挑战，运维能力要求更高了，开发人员定位线上问题也更困难了。所以，有的时候微服务真的很适合我们的项目吗？从这个时候我开始有这个疑问。

        再后来就职于一家中等规模公司，公司的核心业务也是直接上了springCloud-alibaba全家桶，明明公司的业务流量很低，都不说秒流量，日流量能有几十都很少见，在这种情况下，依旧选择微服务全家桶，甚至流控组件都不放过。只能说，对技术人员来说，挺好，流行的东西都玩了，简历又丰富了。但是对于项目来说，真的没必要。微服务架构需要开发人员，运维人员更强的技术水准，日常工作中，也比如做更多的工作。

        最后说说我的感受。现在的java-web开发这一块，大部分企业一上来就是微服务，云原生这些东西，但是，真的有必要么？企业有那么大体量的业务，那么高的并发，需要用到这些技术吗？技术高层最喜欢的一句话，方便业务拓展。但是实际上，真的有那么多的业务拓展吗？而且，初期设计的架构，如果连一两年的业务拓展都考虑不到，是不是这个架构多少有点儿失败了？而如果这个所谓的拓展出现在了三四年之后，或者项目大火之后，是不是可以考虑直接启新版本做整体技术升级了？

        所以，综上，我的个人感觉是，两类项目可以一开始就考虑微服务，一种是确实是大公司的大型项目，用户体量，业务体量都摆在那儿，确实需要微服务来解决高并发访问，单服务体量过大，拓展性不佳等问题。一种是平台型业务，因为经常需要对接适配，所以业务复杂性极高，灵活性要求极高，可以使用微服务来做一些业务解耦。而对于中小公司和创业者，如果做的业务本来就比较单一，且短时间内访问量也不会太大，我觉得一个spring Boot项目搞集群部署，绰绰有余。如果之后项目火了，访问上来了，业务也该扩容了，再进行技术升级，扩展开发团队，也比一开始就大张旗鼓搞cloud，结果项目进度也慢了，团队要求也高了，最后项目被拖的解散要好.