整體架構

這個圖適合中小公司。麻雀雖小五臟俱全。微服務架構所需要做的事在這個圖里基本都有了。

綠色的不講，主要講的是這三塊（橘黃色的）。后面的和運維相關，會講，不會講的太深

訂單服務

首先來寫一個訂單服務

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