微服務(wù)架構(gòu)可以說是目前最流行的架構(gòu)了，我終于也要上這條船了，為什么要上這條船呢，只是為了時尚嗎？呵呵，當(dāng)然不是，上這條船是為了實用的。
先說說現(xiàn)狀?，F(xiàn)有的系統(tǒng)簡單、粗暴。開發(fā)是采用c#和dotnet framework 4.5框架，部署采用的是單節(jié)點單實例的方式來部署的。在一臺windows云服務(wù)器的IIS中部署多個站點。只是簡單的做了業(yè)務(wù)分層，把后臺API獨立為一個站點。對外服務(wù)的網(wǎng)站和公司內(nèi)部使用的管理系統(tǒng)各自獨立為一個站點，并和微信小程序、APP都依賴于一個webapi站點提供服務(wù)。在這種架構(gòu)模式下。發(fā)生過很多次網(wǎng)站宕機的情況，還出現(xiàn)整個服務(wù)器宕機，必須重啟的情況。
在公司初創(chuàng)初期，這套系統(tǒng)以最低的成本為公司的發(fā)展提供了足夠的技術(shù)保障，但是隨著業(yè)務(wù)量的逐漸增長，這套架構(gòu)已經(jīng)不堪重負(fù)了。所以，是時候重構(gòu)整個系統(tǒng)了。目標(biāo)就是提高整個系統(tǒng)的可用性、負(fù)載能力和可維護性。為公司下一步業(yè)務(wù)的增長提供一個堅實的依托。
架構(gòu)選型
其實也沒什么好選的。目前最流行的就是微服務(wù)架構(gòu)了。而且這套架構(gòu)也確實能提高整個系統(tǒng)的可用性和負(fù)載能力。
實施選型
框架選定了，怎么實施呢。在實施的時候要遵循什么原則呢。結(jié)合我們的業(yè)務(wù)需要和團隊技術(shù)背景能選的方案其實并不多。一個微服務(wù)架構(gòu)由那些東西構(gòu)成呢。第一個就是提供某種業(yè)務(wù)能力的服務(wù)了（廢話），有了業(yè)務(wù)服務(wù)就要有一個東西來管理這些服務(wù)，提供起碼的服務(wù)注冊和服務(wù)發(fā)現(xiàn)以及服務(wù)健康監(jiān)控能力。為了提高系統(tǒng)的可用性和負(fù)載能力對于熱點微服務(wù)肯定需要部署多個實例，并在這些實例上進行負(fù)載均衡和流量控制。同時還要把這些多實例的情況進行隔離，讓調(diào)用者看起來猶如一個服務(wù)一樣。服務(wù)多了，就需要為這些服務(wù)提供統(tǒng)一的身份認(rèn)證，讓系統(tǒng)的水平擴充簡單方便。為了提高系統(tǒng)的維護性就需要有監(jiān)控和審計的能力。
基于以上需求，要實現(xiàn)微服務(wù)架構(gòu)除了服務(wù)本身之外還需要一個服務(wù)管理中心來提供服務(wù)注冊、發(fā)現(xiàn)和健康管理能力。需要一個API網(wǎng)關(guān)來實現(xiàn)負(fù)載均衡、流量控制、身份認(rèn)證、日志收集系統(tǒng)監(jiān)控和調(diào)用隔離。
在經(jīng)過多方考察后最終決定使用如下的方式來實施微服務(wù)架構(gòu)。
開發(fā)語言和技術(shù)框架
開發(fā)語言依舊使用C#，技術(shù)框架選用dotnet core 2.0。采用這套技術(shù)框架的遷移成本是最低的啦。
微服務(wù)
微服務(wù)采用dotnet web api進行構(gòu)建，服務(wù)間的調(diào)用也用webapi的方式調(diào)用。
服務(wù)管理中心
服務(wù)管理中心采用consul來實現(xiàn)。
API網(wǎng)關(guān)
API網(wǎng)關(guān)基于Ocelot進行定制開發(fā)。
部署
微服務(wù)全部采用docker的方式部署。
實施步驟
搭建實驗部署環(huán)境；
開發(fā)原型系統(tǒng)；
在實驗環(huán)境中部署原型系統(tǒng)；
進行故障測試、可用性測試和可維護性測試。
