整体架构
这个图适合中小公司。麻雀虽小 五脏俱全。微服务架构所需要做的事在这个图里基本都有了。
绿色的不讲，主要讲的是这三块（橘黄色的）。后面的和运维相关，会讲，不会讲的太深
订单服务
首先来写一个订单服务
从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
说明我调用价格服务调用成功了。
就做这么个简单场景，下单然后价格服务 查一下价格