spring cloud多模块项目框架搭建-前言

   第一章-前言

本系列博客旨在搭建一套能用于实际开发使用的高可用，高性能的spring cloud多模块微服务项目框架，并不是一个spring cloud的demo而已，提供系统的开发规范限制，微服务注册中心，配置中心，负载均衡，熔断，redis缓存，分布式事务，kafka服务消息通信，系统安全（sql注入攻击，xxs攻击等等），多数据源切换，全局异常处理等等。

 目录顺风车：

spring cloud多模块项目框架搭建 ：spring cloud多模块项目框架搭建-目录_百块富翁的博客-CSDN博客

在正式搭建开始前，本章先吹吹牛，说说废话，下面按我自己的理解笼统的说说这几个问题，完整的还是看官方的解释，我觉得在正式搭建这套架构之前一定要搞清楚的一些问题，不然就有很多小伙伴要问一些很无脑的问题。

1.         什么是架构？

按我的理解，广义的说架构就是一栋房子的地基和结构，指导和决定了这套软件的走向。一定程度上决定了开发时难易程度如何，软件成型之后的性能如何，代码质量如何，后期维护成本如何，项目迭代扩展成本如何！！！狭义来说，就是一系列抽象的结合。开发人员就是这工地上的干活的，装修的，搬砖砌墙的，只是在这个地基的基础上使这套房子更适合人居住；让这套系统完成特定的功能，客厅？卧室？。为这些干活集合了许多工具，规定基础组件，避免我们代码书写过程中重复造轮子，定义了软件系统的规范，比如选用什么数据库，通信，访问的交互方式等，就好比不用这些干活的再去造水泥，炼钢铁造钢筋，定义他们的施工规范，监督他们的施工质量，提升他们的施工速度等等。

2.       怎样设计架构？

网上任何一篇关于架构怎样设计的文章，博客，至少少不了两千字，长话短说，在我看来，架构是出发点是基于业务背景和使用场景为依据，以业务来决定技术，以这套架构在广义上把系统性能最大化，承载和规范，简化开发人员开发过程，从而使后期的维护难易度维护最简化。再放眼未来一段时间，你的系统能持续扩展,发展。一套架构设计出来，并不是要你选用的技术多么多么牛逼，微服务分了多少多少个，系统多复杂或简洁。现在好多公司，自己公司内网十几个人用的库存系统，他还非要你给他设计成微服务，分布式。其实大没必要，我敢说一套简单的ssm系统在这个场景下比要求的分布式的性能高出至少40%。再比如说，jd，淘宝的支付结果，使用的是长轮询，有人说长轮询多老旧了，websoket多牛逼，多及时啊，那有没想过基于这个具体的场景，在用户可接受的延迟下，谁给服务器造成的压力更大？一百个人用和一万个人同时在线的设计，完全是两个概念。总而言之，适合自己业务的架构就是好架构，技术没有老旧优劣之分，适合业务的就是好技术！一套好的架构设计能使系统性能提升10%（这个主要是业务代码层面，但是系统设计也不能忽略），简化开发工作25%左右，后期维护及扩展难度减少60%。

架构设计思路总的来说以下3点:

a.业务：业务背景，使用场景，业务关联性，业务边界

业务背景：还是上面说的任何技术，设计思路基于业务出发，比如设计一个办公财务软件和设计一个参加双十一的商城的设计思路是不一样的；

使用场景：比如1000个人使用的商城和10万qps的秒杀商城的设计思路的和技术选型。

业务关联性，业务边界：这就是具体实践过程中的细节，在微服务拆分的过程中更明显，我们在业务最小粒度化的拆分时就需要特别注意这两点。

b.技术实现难度及技术应用场景：这里就是说不能一味的追求新技术，所谓的好技术，要考虑技术契合度和目前团队目前的技术实践难度。

c.交付时间及演进周期：这里就是和老板的相处之道了，这系统要1个月上线，结果你要追求完美，拖两三个月，等你做出来黄花菜都凉了，市场都被别人夺走了，原因就是追求你的好技术，市场都没了，再完美的技术都没啥卵用，再就是一个系统发展都会经历一个发展阶段，淘宝，京东，十年前你就想做成现在这样是完全不现实的，这就需要和老板沟通产品的一个发展路线和推广计划，提前做好技术预案和留好扩展方向。

d.系统持续的扩展性：系统发展难免会遇到性能瓶颈和需求更新，你不能只顾堆屎山，来个需求就搞个需求，只管堆，搞得谁也维护不了，来个需求今天要重构一次，明天又重构，那就完犊子了，你的开发兄弟要跟着你007，老板也不待见你。所以在设计之初就要考虑好整体走向，任何一个需求点能进行抽象的都要高度抽象化的设计，为未来发展提前铺路。

e.高性能，高可用：这个下面单独提出来讲。

3.       微服务和分布式的关系

说到这个，我开始接触分布式的时候也分不清楚，懵的。

以前一套系统的访问量不大时，一个商城的商品，订单，支付都是在一个系统里面的。而当用户量越来越大时，一套系统一台机器撑不住了，怎么办呢？

     1.1.  第一种解决方案：一台撑不住，那我就横向扩展嘛,多部署几台乃至成百上千台，这就是分布式。

     1.2.  第二种解决方案：上面一个系统部署很多台，还是撑不住呢，不但部署不方便，而且造成了很多系统资源的浪费，很多时候，例如商品模块的访问流量远远大于支付的，这时候我就把商城系统的商品，订单，支付分拆成三个独立的系统，按需尽可能细的拆分（这里有很多分拆法，不做具体讨论），再独立部署，协作通信完成系统功能，纵向扩展，这就是微服务。

为什么我们容易把分布式和微服务弄混淆，就是这二者很多时候都是相互依存，并不单一存在。综合以上来总结：微服务是一种架构设计方案，而分布式是一种系统部署方案。这里有人可能会抬杠，那集群和分布式又怎么区分呢？这里是说分布式和微服务的区别才这样解释，要说到集群，就又要细分一些，把微服务的某一个节点多部署几台，这个就叫做集群，这又要分为横向集群和纵向集群。一台满负荷了或挂了，另一台顶上，叫做主备集群，这属于纵向集群，还有一种就是把一个费时，废性能的任务或者是一台或几台处理不了的，拆成好几个任务，部署到几台机器上跑，一台机器只处理其中的一部分，让他们一起运行，这就是常说的横向集群，集群和分布式很相像，可以把集群理解成分布式的子项。不管是分布式还是微服务，亦或是集群，最终都是为了实现系统的高可用，高性能。

4.    什么是高可用，高性能？

这个问题也很有必要拿出来聊聊。网上很多的文章大多都说这是一种主备集群模式，master挂了，备用节点顶上，达到系统的持续可用，叫做高可用集群。这一点是没说错，但是太过片面了，这只是一个实际运用的详例。

按我的理解，高可用，高性能是系统架构设计过程的思想指导方向和最终架构使用期许。稳定性，安全性，可靠性，维护性和易用性都是高可用系统的必备条件，缺一不可，不管是集群模式，还是系统设计，亦或者其他。高性能则是在上述条件下，将系统及硬件的性能发挥最大化，换句话说尽可能多，快的运行程序或提供服务。

4.1 稳定性：这也是我们大多数人所理解的高可用，系统能持续使用，不宕机(准确说减少系统引发的宕机原因)或尽量的减少服务不可访问时间，系统资源使用平稳，这是高可用系统的最直观表现。

4.2 安全性：系统在持续提供服务时，能对系统安全，数据安全，设备安全提供保障。将一些怀有非分之想的人阻拦在外，比如xxs攻击，数据篡改，恶意请求等等，这几点不能保障，系统虽然能提供服务，但与我们设计使用的功能都背道而驰了，谈何高可用？这一点也占到20%。

4.3  可靠性：这个和安全性有些许重叠，但是也有不同之处。可以说安全性是对外，而稳定性是对内。可靠性占到20%。

           4.3.1  负载均衡：总而言之系统在设计就应该考虑机器的性能的瓶颈，资源要均匀分配，不能闲的闲死，累的累死。否则当第一台过量负载就会宕机，接下来就是第二台，第三台，接下来就可能造成多米诺骨牌式宕机，直至整个系统雪崩式崩溃。还有一点比较容易忽略，就是过量请求拒绝，比如我们系统只能最大承载2000个请求，当这一刻突增至3000个请求，这时候就要懂得拒绝，可以采用软性拒绝服务和硬性失败，软性拒绝就比如加入排队队列，让用户等待，比如转圈；硬性拒绝直接失败，拒绝请求，比如我们常遇到的系统繁忙。

           4.3.2  用户提交校验，执行顺序，多线程环境等等，这些都要根据业务在框架上做出一些处理，或者说提供对数据脏读，错误的预防和恢复手段。

4.4   易用性：我们的系统架构设计出来，使用群体包括开发人员使用，测试人员，用户，设备（面向对象的思想来说，它也是一大用户），维护人员，系统对这些群体使用时都要达到简单友好易用，比如设备，它的易用性就是省除一些不必要的运行，也就是性能，就像我们这套系统在持久层隔离了pojo参数承载层的，这样持久层在运行时就省去了一些解不需要的运行，比如视图层的注解。再比如系统需要维护人员要配置啥，设备喜欢的就是二进制，你能维护人员去写二进制吗？就算要写，你也要提供相应的转化工具啊。

4.5    维护性：还是引用上面，我们机构及系统的使用群体包括开发人员使用，测试人员，用户，设备（面向对象的思想来说，它也是一大用户），维护人员。系统在考虑维护难易度或是可扩展方面时也需要全面兼顾。

以上5点，也就是高可用的组成的必需条件，我们这里主要侧重于系统来讲，稳定性40%，安全性20%，可靠性20%，维护性和易用性各10%的组成比重，任何一点不能保障，那就是个假把式的高可用系统。

高性能在满足以上先决条件下还应该满足以下几点：

      合理负载：比如在4.3.1 提到的单个服务不同节点机器负载均衡，只有当各个组件负载平衡，合理负载，只有在服务自己合理负载范围内，才能将性能最大化。

     合理拆分：上面说了单个服务不同节点机器要合理负载，服务之间也要实现合理负载，这就比较考验在服务拆分时对业务的熟悉度和整体把控，只有对业务拆微服务时拆的合理，才能实现灵活部署，服务层面的负载均衡。

     合理代码：这个对高性能至关重要的，但是在框架层面能约束的很少，但是对系统架构来说最明显的就是控制技术选型了吧。

5.       spring boot和spring cloud的关系

  5.1   什么是spring boot？

Spring Boot 是由 Pivotal 团队提供的全新框架。Spring Boot 不是Spring 的替代者，Spring Boot 是所有基于 Spring Framework 5.0 开发的项目的起点.是为了简化搭建，开发spring应用而生，让用户可以实现以最少的配置甚至零配置更快创建spring应用和集成其他框架，遵循“约定大约配置”，也就是你遵循它定好的约定，比如配置文件名，就可以享受到它的便捷之处。其实spring boot和maven有异曲同工之妙。从最根本上来讲，Spring Boot 就是一些库的集合，集成了大量常用的第三方库的配置，由此 Spring Boot 应用为这些第三方库提供了几乎可以零配置的开箱即用的能力，海纳百川的感觉，就像一滴水你只要按着我江河的路径的约定不跑偏了，一定能到达大海。

  5.2  那什么又是spring cloud 呢 ？

我们先看看官网的解释：

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns. They will work well in any distributed environment, including the developer’s own laptop, bare metal data centres, and managed platforms such as Cloud Foundry. 

说的什么意思呢，就不一一翻译了，大概意思就是说Spring Cloud为开发人员提供了工具，以快速构建分布式系统中的某些常见模式（例如，配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁，lader选举，分布式会话，群集状态)。按我的理解，spring cloud 就是继承了spring boot“零配置”的便捷性，提供了一系列分布式组件，集成了spring cloud start还不算是spring cloud服务，他这一系列组件的合起来才叫真正的spring cloud，最大程度的简化了我们分布式基础组件的开发。

    5.3   spring boot和spring cloud 的区别是什么？

由上面我们可知，spring boot 依赖于 spring，而spring cloud又依赖于spring boot。都是用来简化我们的系统的搭建和开发。spring boot更专注于解决简化单体应用的搭建及开发过程，更像是一个快速开发框架，spring cloud致力于整个微服务的整套解决方案。

6.      为什么写这个教程博客

至于为啥要写一系列博客，以前也写一点博客，就是记录记录问题。前几天看了《捌佰》这部电影，还是特别用感触，跳楼，护旗，过桥这三段，我一个大男人都看的流泪了，想想那时我们国家强大一点，倭寇何敢？又何至于以身破盾，护旗？我们国家现在国家虽然强大了许多，但是大家想想这一年来中兴，华为，字节跳动的遭遇，我们国家还是很被动，就连自己的香港，台湾都甘愿被西方国家当枪使，我们再强大一些，自己的孩子又怎愿对他人投怀送抱？？还有我们周边各国，哪个对我华夏不是野心蓬勃，虎视眈眈，日本，韩国，印度阿三及东南亚各国有事没事来找事，如此种种，归根结底还是我们不够强大。

就拿我们编程这一行来说，看看我们用的编程语言，这些软件，工具，80%不是国产的，如果今天西方国家像限制华为这样把这些所有软件，语言切断，我们该当如何？？我们国家实话来说，很多方面还是有一些差距的，这是我的真实感受，不管这句会不会被人喷。

丈夫当立报国志，寸力亦能壮山河。这是我看完《捌佰》的第一感受。而今我们90后也到了而立之年，正是社会的主力军，小时候总想着长大以后要干啥干啥，长大后却很少再这样想。我虽然不能像军人保家卫国冲在第一线，也不能像那些商业大亨为国家创造多少税收；我的技术也不是很牛逼，但是入行也好几年了，自己这一路来也不是太容易，如果能帮助后来人，也算是为国家出了一丝微薄之力吧，要是这些人中有那么几个为国家出了大力，我岂不是也是功臣，也沾沾光。哈哈，梦还是要做，万一实现了呢，自己实现不了的事，就交给梦和别人吧！！！

话说回来，我国人都是这样的心态，何愁国家不能复兴？其实很多事情都是这样，要的不是你能出多大的力量，而是一份态度。

不说国家那么深远了，自己好好学习，技术提高了，第一直观表现不是水群吹牛逼更有信心了吗，工资到手的也多了，难道不香么。以上说了这么多（不是废话哈，至少这报国之心不是），做了这好几年的Java程序员，开始几年也没好好学习，下班就是打游戏，有好多时候还因为前一天晚上打游戏起不来耽误事，耽误上班。好在这两年醒悟过来了，我自己觉得有点迟了，浪费了好几年的大好时光，甚至那个心爱的菇凉的遗憾也与这有莫大关系。看到这里的年轻人，由衷的说一句，你在游戏上没啥特别的天赋，就不要在上面浪费太多时间，那只是游戏而已，娱乐工具而已，偶尔玩玩，和酒一样，小酌怡情。哎，又说上了废话。

以上也就是我要写这一些列博客的初衷和几个开始就得明白的理论，因为是按我的自己的理解总结的，不了解的童鞋强烈建议去找找这几个名词的详细解释说明，接下来几周将持续更新。以自己的方式为国家，为这个圈子出我自己的一份力，也是对我能力的检验。可能水平有限，但是初心还是好的，今天就写到这吧，看到这里的各位，共勉，不足之处还望多多指教，大家共同进步成长。

上面所写内容如有不足和纰漏，欢迎留言或私聊指正批评。如果需要转载，也是欢迎，不甚荣幸，但请把《spring cloud多模块项目框架搭建》这一系列博客全部一起转载，这一系列博客毕竟是个整体教程，如果别人只看到一部分，那就是个残次品，谢谢，鞠躬。

             立 世 不 思 图 报 国，匹 夫 耻 作 男 儿 身。   --任惜若

今天的文章spring cloud多模块项目框架搭建-前言分享到此就结束了，感谢您的阅读。