这是陈东景于2021年8月21日晚23点原创作品，转载请标明出处！！！！
所谓微服务就是一个独立的颗粒度不大的能独立运行也能对外提供服务接口的代码集合。
微服具备两个功能:1.能独立运行，2.能对外提供服务接口。从这两点可以看出，微服务首先是一个工程，JAVA里的Project，其实就是一个小项目。第二，微服务里的服务，指它是可以对外提供接口和数据交互。所谓对外，就是别的服务或者别的应用系统，这就叫具有服务功能。合起来就是微服务啦。
传统的java project编写不会对外部project提供接口，所有的调用关系都只在一个project里完成。这种project结构叫单体结构。由于互联网技术和业务的发展，业务越来越复杂，项目规模越来越大，研发团队人员越来越多，一个单体的project很难实现复杂的业务场景，要么耦合度太高，要么性能不够，可靠性不够，开发人员不易分工开发，部署不能保证服务的连续性，需要关闭服务部署或者停顿功能部署，做不了灰度测试，各种依赖过于紧密，后期遇到需要重构的成本过大，不易优化升级等等诸多问题。可以说对于21世纪互联网应用系统来说这种单体的project一无是处。只适合学校里玩个demo教学。
那么解决办法来了，搭建微服务分布式系统，很好的解决了上面的问题。我们可以把原来的单体结构的project进行业务或者功能进行拆分。一种类型的功能集或者一个功能就可以做一个project，n个project组合，之间完成通信组合完成单体结构的业务需求。这样做的好处是，1.每个project都是一个小的project，模型基本一致，业务流程简单，开发简单。2.可无限横向扩展，实现无数的业务功能，解决了业务上耦合度过高的问题。3.每个Project都可单独运行，不依赖与其他project，开发者无需关心其他服务（project）的开发进度，只需专注自己业务和接口实现。4.可进行分布式部署，想部署到哪个机器就部署到哪个机器，无需都部署到同一台机器，而且还可以部署多个。5.想啥时候关机就啥时候关机，不影响其他project的运行，只需部署多个进行负载均衡提供服务即可，停掉一两个服务根本没影响也没知觉，可以做灰度测试和灰度发布。优点太多，是当下互联网网时代的宠儿，也是当下主要互联网开发架构模式。那微服务系统是由什么构成的呢。经过这几年技术的发展和集成操作，搞出了一个叫springBoot的玩意。其实他就是一个java project，基于spring，做了一些集成，简化了一些以前的配置文件，然后起了一个时髦的名字，让你感觉又新颖又喜欢，你也可以认为它就是spring的一个儿子，只是这个儿子青出于蓝而胜于蓝罢了。作为码农，如果spring都不知道的，肯定找不到工作了，或者工资会很低。我们要感谢spring，它让我们对java技术充满了幻想，也让我们迷茫。spring是一个非常好的java技术生态，它几乎集成了JAVA里所有的数据类型，数据结构，开发流程，通信协议，设计模型，尤其是设计模型，非常经典，非常成熟，非常迷人，给人无限的灵感和想象空间。很多人对spring只停留在AOP和IOC，这是进价架构的绊脚石。哈哈哈。
废话不多说，那怎么搭建一个基于SpringBoot作为微服务的SpringCloud架构呢。我基于我现在在公司的项目结构简单描述一下，不喜勿喷。
我们的前端采用目前流程的Vue进行页面开发，这属于前端。后端我们设计好数据库表以后，采用代码生成工具通过配置后逆向生成Springboot脚手架，也就是一个java projet的骨架。输出的目录和文件包括几个模块（这里由于数据公司项目，不方便截图展示）：
1，main
2， api
3，client
4 ，provider
5，mapper
6，pom文件。
7.resource
其中
main里定义的是springboot的启动类，这个是springboot能单独运行的钩子。
api里定义的是服务内部的接口，数据库表实体类VO，数据库表扩展类BO ，这一层是供服务内部使用的，restful的风格，可以被Vue前端通过URL调用。
client里定义的是提供给外部服务调用的接口，这里的接口实现了api里的接口，使用feigin 的方式提供给外部服务调用，这也是springboot能做成微服务的技术手段。和一般java project 最显眼的区别。
provider里定义的是controller 和 service，还可以定义其他扩展的业务处理模块，这就是经典springMVC里用来做业务处理的模块。其中controller实现了api里的接口，接收前端URL的请求，返回请求结果。service里实现了具体的业务处理过程，实现数据库接口的调用，封装返回结果，提供给controller调用。所有的什么数据类型定义，对象，什么 if、else 什么 for 循环，什么使用什么List hasMap set ArrayList 各种集合 什么牛逼的算法，什么事务处理，多线程 ,组装返回结果，redis缓存，MQ消息队列，SQL拼接通通在这里搞，这里实现，这就是日常程序员说的做功能开发，coding ,coding 编码实现就是这个玩意。如果我们想调用其他微服的功能和方法也是在这个service里搞，只需要声明并注入其他微服务client 里的service，就可以直接调用方法，进行业务处理。这里不知道说清楚微服务之间的调用关系没有？
mapper里定义了mybatis的接口，各种增删查改的方法就配置在这里。
pom文件就是maven，jar包的管理，project里需要依赖的jar包，服务，项目名称，版本，构建方式等。
resource里定义的是mapper里mybatis的接口对于的XML，各种增删查改的SQL就配置在这里
一个springBoot的基本骨架就上面这几个。简简单单。一个服务算是完成了。我们可以按照上面的方式构建一个又一个不同功能，不同业务类型的服务。这是构建SpringCloud的基础。
那怎么搭建一套SpringCloud呢？
经典的搭建模式，我们按照上面搭建SpringBoot的方式分别搭建出 注册中心服务，配置中心服务，网关服务，基础功能服务，n个业务服务，集中发布服务。
注册中心服务（zuul）：服务治理专业户，主要功能服务注册发现。
配置中心服务：对开发过程中需要配置的文件进行集中管理。
网关服务：解决服务之间调用关系的路由。
基础功能服务：开发共性的基础功能，减少重复造轮子。
n个业务服务：每个业务的实现，java程序员每天忙里忙外，开发调试，下一个蛋又一个蛋，挖一个坑又一个坑的坟场，这里埋葬了大多数程序员20岁到27岁的青春。
集中发布服务：专门做服务集成部署的服务，完成一键部署的福音。
大致就上面这几个吧。因为每个服务的实现逻辑对外部服务或者对不参与服务的开发的程序员是 透明的，程序员只需要知道返回结果或者接口协议即可使用。这一天部署起来，就是最简单的SpringCloud了。共享，透明，为每个服务的实现逻辑对外部服务或者对不参与服务的开发的程序员是透明的（就是看不见，看不见，也不知道怎么实现的，像马士兵以前培训经常说的不关心里面的实现（这一句话害死很多程序员无法进价，正如我们每天用着spring，从来不关心它的实现，一出去面试什么都云里雾里）），程序员只需要知道返回结果或者接口协议即可使用，因为这个原因使人云里雾里，所以美其名曰：Cloud的。所谓云就是透明，共享。这个思想是我在2010年中南大学的时候听张尧学校长说的，记忆深刻，要错也是它的错。他们团队搞得透明计算获得过国家技术发明一等奖，500万的奖金。所谓透明计算就是现在各大厂程序员云里雾里，张口就来的云计算。
今天就写到这里吧。下一期讲讲docker部署，本人从事JAVA开发已经7年了，一路坎坷。我觉得无论我们的初衷如何，如今行走在何步，都应该对未来充满信心和希望，干一行爱一行，希望能给大家传播正能量，也希望次博客对你们有用。 ———————————————— 版权声明：本文为CSDN博主「gulf_china」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/dongjing991/article/details/119844854
