SpringCloud系列 1 初試微服務

微服務

之前在寫springboot的筆記時，就有提及到springcloud。springcloud提供了微服務的開箱即用。微服務近年來非常火，到處都在說微服務。筆者也對微服務相當感興趣，因為筆者在校期間（n年前）曾經和很多同學聊過，如果所有的應用並不是單體的，而是通過很多系統提供api這會變成怎麼樣，當時我就覺得這樣能夠做到分布式服務。因為服務是分離的，我們可以針對每乙個不同的服務，調整負載均衡的裝置數量，提供更多的資源給到負載較重的服務。但是在考慮的時候也發現了很多技術的問題，例如如何在多個伺服器提供強一致性的事務管理，服務服務之前應該通過什麼方式去呼叫（http?nio?amqp?），太多太多的問題導致我認為當初這個想法是不切實際的，可能是以前技術水平並不高的原因吧··· 雖然現在也不高。慶幸的是，n年之後的今天高流量負載的網際網路推動了微服務。當年我想的問題，至今已經有了非常多相應的解決方案，讓我對微服務充滿了未知的興趣。

為什麼我會選擇寫springcloud的筆記？目前有很多很優秀的微服務框架，例如阿里的dubbo。很簡單因為dubbo有很詳細的中文文件，想學或者忘記了可以查dubbo的文件，但是對比與springcloud，筆者認為dubbo效能會更佳，因為springcloud 主要的通訊協議使用http(rest),amqp。但是筆者因為http的短板是每次通訊都是需要建立連線效率上還是有所欠缺，而dubbo是提倡使用基於nio的通訊，對於大吞吐量有非常大的優勢。但是不管怎麼說，springcloud也是相當優秀的框架，在近些年來springcloud的版本發布速度也是快得離譜，詳細springcloud會越來越完善。而且springcloud基於springboot提供給我們非常簡單的配置和操作，學習一門分布式框架有助於你理解分布式的其他架構理論，畢竟打過仗再去看兵法，比紙上談兵效果很好嘛····

其實在分布式最為困難的是，如何去換分服務。這是非常困難的，往往需要非常多經驗的沉澱。筆者不才~ 但是個人覺得，按照伺服器是否存在強一致性去劃分比較好。因為網路是不穩定的、容易出錯的，所以對於一些強一致性的業務最好不要分。不過，如果出現邊界模糊、服務過於複雜你也得分，但是這樣你就要在容錯技術上做好充分的準備，如何做事務補償機制、如何保證一致性都是等著你的問題。但是筆者對這部分還是有相當多的空白，所以筆者在外來一段時間會看一些關於領域驅動設計的書籍，如果覺得不錯，也會csdn寫相關的部落格，也會推薦相關的書籍。

寫了那麼多，第一次寫這麼多理論的東西。不管怎麼樣，我會在我的筆記嘗試解答著一切，以後無論是其他開發者看到我的筆記也好，或者是我自己工作遇到這些技術需求也好，希望這些筆記可以幫助到我或者你們。

我們開始之前如果你對springboot不熟悉，可以移步先看看springboot【springboot系列(1)---無配置檔案配置基礎1】，如果你連spring都不熟悉，也可以先看看spring。

一、初試微服務

先說說業務，目前筆者所在的團隊主要是開發電商系統的，所以我將會以電商的業務作為業務模型，相信都網購過也不用多說業務上的東西了。

我們會建立三套服務，商品服務、使用者服務、訂單服務其他什麼倉儲物流、**系統、評價服務、**等等就不搞了。簡單明瞭去認識服務。

簡單點，商品服務提供商品查詢，有兩個引數使用者id和商品id，根據使用者id從使用者服務中獲得使用者資訊（通常都會新增商品訪問日誌用於資料分析、通過**系統、驗證優惠資訊操作都需要用到當前登入的使用者資訊）由於方便，我們就不用redis做使用者登入的token快取了，實際環境自己發揮·····

先建立兩個專案，乙個是商品服務系統、第二個是使用者服務系統。

在使用者服務系統我定義了兩個介面，以下是介面的controller：

@restcontroller
public class usercontroller 
public user adduser(string username,string password,long balance)
}

在商品服務系統，我定義也定義了兩個介面，以下是商品服務系統的controller：

@restcontroller
public class productcontroller 
public map, object> getproduct(@pathvariable 
int productid, 
@pathvariable 
int userid) 
}

public static void

main(string args)

@bean

public resttemplate resttemplate()

}使用者服務系統配置檔案如下：

server.port
=8801
server.context-path
=/user
spring.datasource.url
=jdbc:mysql://localhost:3306/shop_mall?charset=utf8mb4
spring.datasource.driver-class-name
=com.mysql.jdbc.driver
spring.datasource.username
=root
spring.datasource.password
=tonyyan

商品服務系統配置檔案如下：

server.port
=8802
server.context-path
=/product
spring.datasource.url
=jdbc:mysql://localhost:3306/shop_mall?charset=utf8mb4
spring.datasource.driver-class-name
=com.mysql.jdbc.driver
spring.datasource.username
=root
spring.datasource.password
=tonyyan

可以看到筆者兩個專案都是連線相同的資料庫，但是在實際的微服務上大可不必。由於資料庫的連線池非常容易在極端場景打滿，所以不同的服務可以使用不同的資料庫作為持久化層，而且可以針對每個服務的特性去選擇資料庫也是非常常見的做法，如果資料量大，查詢速度上有要求，也可以在這些服務系統上使用mongodb或者hbase等nosql資料作為持久化層。

測試介面：http://localhost:8802/product/getproduct/1/userid/1

json返回如下：

,"user":

}簡單的我們已經可以發現幾項問題：

1、我們的訪問url是寫死的，如果目標服務有變，訪問介面也需要變。

2、訪問的伺服器不是高可用的，更加不用說負載均衡了。

下一遍筆記將會解決上述兩大問題。

SpringCloud系列 1 初試微服務

Spring Cloud系列勘誤

SpringCloud系列八 Hystrix 簡介

SpringCloud系列十二 Zuul

SpringCloud系列 1 初試微服務

Spring Cloud系列勘誤

SpringCloud系列八 Hystrix 簡介

SpringCloud系列十二 Zuul

相關推薦