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里面

服务修改端口

因为要同时启动两个应用,所以要指定不同的端口

创建pplication.yml配置文件。

server.port



从order服务复制一个到price的服务


启动服务测试

启动orderApi

启动PriceApi
 


这里端口改成9060





说明我调用价格服务调用成功了。




就做这么个简单场景,下单然后价格服务 查一下价格

结束

 

posted @ 2019-11-26 00:21  GASA  阅读(930)  评论(0编辑  收藏