微服務架構可以說是目前最流行的架構了，我終於也要上這條船了，為什麼要上這條船呢，只是為了時尚嗎？呵呵，當然不是，上這條船是為了實用的。

先說說現狀。現有的系統簡單、粗暴。開發是採用c#和dotnet framework 4.5框架，部署採用的是單節點單例項的方式來部署的。在一臺windows雲伺服器的IIS中部署多個站點。只是簡單的做了業務分層，把後臺API獨立為一個站點。對外服務的網站和公司內部使用的管理系統各自獨立為一個站點，並和微信小程式、APP都依賴於一個webapi站點提供服務。在這種架構模式下。發生過很多次網站宕機的情況，還出現整個伺服器宕機，必須重啟的情況。

在公司初創初期，這套系統以最低的成本為公司的發展提供了足夠的技術保障，但是隨著業務量的逐漸增長，這套架構已經不堪重負了。所以，是時候重構整個系統了。目標就是提高整個系統的可用性、負載能力和可維護性。為公司下一步業務的增長提供一個堅實的依託。

架構選型

其實也沒什麼好選的。目前最流行的就是微服務架構了。而且這套架構也確實能提高整個系統的可用性和負載能力。

實施選型

框架選定了，怎麼實施呢。在實施的時候要遵循什麼原則呢。結合我們的業務需要和團隊技術背景能選的方案其實並不多。一個微服務架構由那些東西構成呢。第一個就是提供某種業務能力的服務了（廢話），有了業務服務就要有一個東西來管理這些服務，提供起碼的服務註冊和服務發現以及服務健康監控能力。為了提高系統的可用性和負載能力對於熱點微服務肯定需要部署多個例項，並在這些例項上進行負載均衡和流量控制。同時還要把這些多例項的情況進行隔離，讓呼叫者看起來猶如一個服務一樣。服務多了，就需要為這些服務提供統一的身份認證，讓系統的水平擴充簡單方便。為了提高系統的維護性就需要有監控和審計的能力。

基於以上需求，要實現微服務架構除了服務本身之外還需要一個服務管理中心來提供服務註冊、發現和健康管理能力。需要一個API閘道器來實現負載均衡、流量控制、身份認證、日誌收集系統監控和呼叫隔離。

在經過多方考察後最終決定使用如下的方式來實施微服務架構。

開發語言和技術框架

開發語言依舊使用C#，技術框架選用dotnet core 2.0。採用這套技術框架的遷移成本是最低的啦。

微服務

微服務採用dotnet web api進行構建，服務間的呼叫也用webapi的方式呼叫。

服務管理

服務管理採用consul來實現。

API閘道器

API閘道器基於Ocelot進行定製開發。

部署

微服務全部採用docker的方式部署。

實施步驟

1. 搭建實驗部署環境；
2. 開發原型系統；
3. 在實驗環境中部署原型系統；
4. 進行故障測試、可用性測試和可維護性測試。