SrpingCloud微服务项目的理解

这是本人做分布式项目的总结，新得体会。如果你与更好的方案欢迎指出

对微服务项目的个人理解

微服务与 SOA/ESB 的异同
微服务和 SOA 都是一回事，强调把整个系统，按照多个服务的方式去组合及通信，而不是揉合在一起，但它们的内涵有很大的区别。
SOA 诞生在早期企业级的应用，其业务复杂、技术体系多样，SOA 强调的是各个服务之间，尤其是异构系统、遗留系统之间，建立起一套统一的协议和通信 (SOAP)，以及寻址服务 (UDDI)，它的侧重点在集成和兼容；与 SOA 同期的另一种概念 ESB(企业总线)，强调通过一根总线服务，把所有服务串联起来，由 ESB 总线来屏蔽各种不同业务系统自身业务 / 语言 / 协议的特殊性，各服务以一种统一的方式，与总线相连，从而降低接入成本。
这两种概念，我感觉在国内没有太发展起来。一是国内的软件起步相对较晚，系统的整体复杂度——多厂商、多语言 / 技术栈、历史遗留系统的问题，还不算突出。而对于公司内部的产品系，又没有必要使用 SOA、UDDI 来做复杂的集成。随着互联网的兴起和用户量的迅速爆发，企业自身的产品的微服务化的需求，快速发展起来，而与此同时 SOA 这种以 XML 为基础的 SOAP 协议、以寻址为主要作用的 UDDI，不能使用互联网产品的发展——SOAP 的 XML 协议内容太多，造成性能明显下降；HTTP 协议的效率不如 RPC；UDDI 只有寻址，缺少服务治理等功能。

在此种大背景下，以服务切分 + 服务注册 + 服务治理 + 限流降级 +RPC+ 监控等为主要内涵的微服务，就快速发展起来的。国内的阿里巴巴走在前列，以 Dubbo 为代表在国内互联网企业中得到广泛应用；后来 Spring 官方发布 Spring Cloud，揉合了一系列自研或其他企业捐赠的开源项目，发布微服务领域的 Spring Cloud 产品。各自都有各自的优势和劣势，而随着这些年来，微服务的继续下沉 (sidecar 和 service mesh) 到基础设施层，给微服务的治理带来了新的方向。

服务粒度
这是个非常值得探讨的问题，下面我们看看粗细存在的问题：
太粗：这服务就涵盖过多的业务逻辑，从而难维护、易出错
太细：就会搞出很多的工程，造成很大的工程维护和通信成本

我这里的切分思想是根据业务来进行切分----业务的切分决定的服务的切分，业务切分也决定了整个项目的团队组织。

业务切分有两种方式：
1、参照业内同类公司的划分：比如电商，业内比较成熟的：支付、库存、订单、搜索、用户等；
2、将自身业务的主要信息流画出来，先找出其中的名词或动名词，它就可能是个服务。
3、也可以根据表的设置方式来决定微服务如何设置，如何架构

我的项目架构方式是将整个项目拆成了： 系统范围、资产服务、客户服务、业务管理

分布式项目是否应该共享数据库
如果是共享数据库那么就开发效率会比较高，比如如果a服务和b服务都要使用到user这张表直接写sql语句就ok了，但是这也会导致sql语句的滥用。当所有服务都这么干那么可能会对应的业务不收悉写出效率比较低的sql语句，或者慢sql语句
如果不共享数据库，那么如果a这个服务要使用到user这张表那么就要找对于user这张表服务的开发负责人沟通。要他写一个接口供a服务调用，这个效率是比较低的。但是由于将编写sql语句的任务给了对应业务的负责人那么sql语句的质量也就得以保障。

我个人的建议啥如果是要应对快速迭代的项目可以先共享数据库，后期当项目成长到一定规模那么肯定是要服务间独立使用数据库。这个还是根据项目的类型和什么要的公司来吧。如果是比较小的公司可能是玩不了的。大公司比较成熟的项目通常采用的都是独立数据库

微服务项目的架构方式

先谈谈架构吧，我们项目前端采用的是 vue+elementUI 跑在 node.js上后端选用的分布式框架是 使用springcloud。

前端请求后台通过zuul网关实现。服务之间调用我们使用的是 feing。好处就是面向借口的风格和内部集成ribbon实现赋值均衡

因为所有请求都通过zuul网关，我们可以在此处做权限验证等请求处理。非常方便。项目部署的时候会将其他微服务统统放入到内网，只有zuul网关放入到外网供外部访问，zuul网关也就成了内部和外包唯一交互的通道。

通用模块（online-loan-cloud-common）设计

通用模块我对他的定义及时项目中各个微服务之间都要用到的一些类，我对此做了向上抽取。

其他的不多介绍了，主要介绍的是entity和 rpc这两个包的作用。

• 每个模块都有自己的实体类所有就建对应的包将他们分离开，也是为了后期好辨认
• entity这个包是项目中所有微服务的实体类的向上抽取，这要做的好处是防止代码的冗余 做到统一管理,主要还是应对feign远程调用的时候以实体类作为参数的时候，消费者和生产者都要提供同样的实体类。所以干脆就直接将所有实体类类全部做向上抽取了。
• 所有实体类都要继承自 BaseEnetity这个类。方便项目中对类型做判断。

rpc包结构：

• 和entity包同理，每隔服务都会有自己的对应feign调用接口，所以这里也做了分包处理
• 每个包中有当前对应模块的feign调用接口
• 可以看到每个包下还有一个hystrix这样的包，这就是每个feign对用的客户端降级处理类。

online-loan-cloud-provider工程和下面的子工程

• 我们将项目按照模块拆分出了online-loan-cloud-provider这些微服务。这里的每个微服务对应一个项目中的模块。
• online-loan-cloud-provider这个模块的主要目方便添加共同的依赖，也就是凡是共同的依赖统统可以放入 到 online-loan-cloud-provider这个服务的 pom.xml中去。二是可以更好的管理项目 层级划分也更好。

每个子工程中的代码就是我们再普通不过的那几个包了：

小结：
前台请求通过 zuul网关，服务内部直接的相互调用使用的是 feign的方式。将所有微服务的实体类我做了一个向上的抽取到了公共模块（online-loan-cloud-common）。所有feign调用的接口也抽取到了公共模块中，每个接口都有与之对应的 降级类。防止服务雪崩

分布式权限验证的方式

我们项目使用的方式是 redis + jwt 这种实现套路。大概是这样的 实现用户在前台登录，后台sys这个微服务检验没有问题后会给客户端发放一个jwt令牌，并且这个jwt令牌会放入到reids中。当用户访问到需要权限才能请求的方法的时候我们可以判断用户是否携带jwt令牌，携带的jwt令牌是否还存在redis中。
将jwt令牌存入到redis中的好处是方便做超时重写登录，和在线将用户剔下线的处理

如果判断一个方法是否需要做权限验证也非常简单，我们可以使用 自定义注解+aop 的思路将 项目中的需要做权限验证的方法打上自定义注解，并且在注解参数中标明这个请求方法需要什么要的权限才能服务，对应权限处理的aop切面类就可以通过前台请求传入的jwt检验了

如何在项目中写出优雅的代码（拒绝硬编码）

直接看我专门写的博客吧：https://blog.csdn.net/qq_43059674/article/details/103738822

分布式项目部署方式

我这里使用的是docker的方式进行部署，直接使用IDEA的docker插件会非常方便哦）：
https://blog.csdn.net/qq_43059674/article/details/103394458
简单的部署一下springcloud项目（这里没使用IDEA中的docker插件部署）：
https://www.cnblogs.com/IT-CPC/p/11985036.html

springcloud 项目中的 坑 ！！

feign调用存在的问题

• feign接口中的方法最好使用GetMapping或者PostMapping 这种方式，对应调用微服务的方法最好请求方式同意一下。如果不统一可能会有问题。

• feign接口如果传递实体类会存在生产者接受不到消费者传递过来参数的情况。这时候要在实体类旁边打上 @RequestBody这个注解就ok了
  

• feign调用不能传递多个实体类阐述，这可能是feign的一个坑吧。@RequestBody在方法上只能大一次，如果要传两个对象你还是使用Map吧