Spring cloud微服务安全实战-4-3常见的微服务安全整体架构

整体架构

这个图适合中小公司。麻雀虽小五脏俱全。微服务架构所需要做的事在这个图里基本都有了。

绿色的不讲，主要讲的是这三块（橘黄色的）。后面的和运维相关，会讲，不会讲的太深

订单服务

首先来写一个订单服务

从user的项目复制依赖到order里面

复制过来了

增加starter-web的依赖

创建包

SpringBoot的启动类也复制过来，改个名字叫做OrderApi

新建order包

创建OrderInfo

新建OrderController

写一个创建订单的方法

创建价格服务

用来查询商品价格

这两个服务可以互相调用

依赖复制一下

创建包

SpringBoot启动类复制过来，改个名字PriceApi

创建price的包

创建priceController

创建要返回的类 PriceInfo

创建返回商品价格的信息的方法

PriceInfo加上属性。

order的服务加上依赖。

price的服务加上依赖。

这样加上@Data注解就不会报错了

这样就有了set方法

创建订单调用价格服务

因为没有搭建注册中心，所以也不把RestTemplate声明成Spring的Bean的形式了。主要讲安全，服务的注册发现和负载均衡就不在这里讲了。直接就去调对面的服务。

商品id通过订单的信息传递过来。订单的实体里面添加一个属性就是为这个商品下一个订单。订单的id

这样就把订单的id传递过来。

服务返回的是PriceInfo

直接把PriceInfo这个类复制一个到了Order的服务下。这里就是重复的代码

微服务架构下最重要的是解耦。解耦的重要性远远大于有些代码重复的重要性的。
如果想PriceInfo不重复。那么一定要提炼出一个公用的jar包来。比如说叫什么common core
这样order和price服务都添加那个公用的jar包引用。表面上看是消除了一些重复的代码。但是增加了耦合性。因为这两个服务都要依赖同一个扎包
那么这一个jar包有变化，实际上影响你两个系统。在微服务的环境下解耦，降低互相依赖的重要性比节省几行代码的重要性要高很多。所以这里面临这种情况就直接复制代码。两边各自改自己的PriceInfo 互不影响。

以上就写了一个价格服务一个订单的服务，然后在订单服务里面去查了一下传进来的商品id的价格。

在PriceController里面