資訊專欄INFORMATION COLUMN
摘要：微服務(wù)架構(gòu)模式使得每個(gè)微服務(wù)獨(dú)立部署，且每個(gè)服務(wù)獨(dú)立擴(kuò)展，開發(fā)者不再需要協(xié)調(diào)其它服務(wù)部署對本服務(wù)的影響。微服務(wù)架構(gòu)模式使得持續(xù)化部署成為可能。所以使用微服務(wù)不是必須的，而是在適當(dāng)?shù)膶?shí)際，架構(gòu)適應(yīng)應(yīng)用場景的一種改變。
問題預(yù)覽近段時(shí)間離職，跟同事們講解我之前所做的微服務(wù)相關(guān)產(chǎn)品，對于同事們提出的問題，做了如下整理出來，加上自己的理解，分享出來跟大家一起探討下：
我為什么要換微服務(wù)？能給我?guī)硎裁春锰帲?/p>
從交互上來看，單體應(yīng)用在處理業(yè)務(wù)實(shí)體之間的關(guān)系，直接由框架搞定，如java的hibernate等，而使用微服務(wù)，還要去花時(shí)間去重新整理甚至重構(gòu)業(yè)務(wù)結(jié)構(gòu).
微服務(wù)測試起來比較麻煩：首先微服務(wù)根據(jù)不同的業(yè)務(wù)實(shí)體劃分資源服務(wù)，那么也許有些業(yè)務(wù)的操作，會(huì)涉及多個(gè)微服務(wù)，那么測試微服務(wù)的話，就需要將所有的相關(guān)服務(wù)都啟動(dòng)完成，才可以進(jìn)行測試。
微服務(wù)一般對外是restful服務(wù)，為了保證安全性，開銷也是比較大的：一方面服務(wù)內(nèi)部可能每次訪問都需要安全檢查，會(huì)降低效率；另一方面內(nèi)部訪問開啟https，在證書部署維護(hù)方面也會(huì)增加壓力
一般情況下，很多服務(wù)都存在類似session等數(shù)據(jù)存儲(chǔ)在內(nèi)存中，而這些session只在同一WebServer中存在，一般無法進(jìn)行多實(shí)例共享（當(dāng)然也有共享的方案，但是需要相對復(fù)雜的集群設(shè)計(jì)），該如何解決這些數(shù)據(jù)的問題呢？
接著上個(gè)問題，微服務(wù)的使用場景中，基本都需要實(shí)現(xiàn)單個(gè)服務(wù)多個(gè)實(shí)例的場景，以實(shí)現(xiàn)高可用，那么問題來了，我對單個(gè)服務(wù)運(yùn)行了10個(gè)實(shí)例，那么該如何知道服務(wù)該向哪個(gè)服務(wù)發(fā)起訪問呢？
接著上個(gè)問題，當(dāng)我運(yùn)行10個(gè)WebServer的時(shí)候，在主機(jī)上需要使用10個(gè)端口進(jìn)行對應(yīng)，而服務(wù)多了以后，對于端口的消耗和管理也是個(gè)比較大的麻煩
接著上個(gè)問題，一般的應(yīng)用，我們可以使用haproxy來做代理，那么就需要每增加或者修改一次實(shí)例，就需要修改haproxy的配置，管理上的消耗也會(huì)成為比較大的麻煩，并且還有可能出錯(cuò)
對于眾多的微服務(wù)實(shí)例，服務(wù)較多的至少可以達(dá)到數(shù)百個(gè)甚至數(shù)千個(gè)，監(jiān)控和管理上，也將比較大的挑戰(zhàn)
上面提到的很多軟件，都是比較零散的軟件堆疊出來的服務(wù)，有沒有比較好的成套的解決方案？
問題及自己的理解 1. 我為什么要換微服務(wù)？能給我?guī)硎裁春锰帲?/b>可以解決復(fù)雜性的問題，在功能不變的情況下，分解為多個(gè)相互協(xié)作的微服務(wù)，通過rest API定義邊界，這樣極大易于開發(fā)、理解和維護(hù)。
微服務(wù)架構(gòu)是的每個(gè)服務(wù)可以由專門的開發(fā)團(tuán)隊(duì)或者個(gè)人開發(fā)者進(jìn)行開發(fā)，開發(fā)者可以自由選擇技術(shù)，不必受制于規(guī)定的技術(shù)和框架，只要API服務(wù)協(xié)議好交互方式即可（如restful）。這樣即使重新技術(shù)過時(shí)的微服務(wù)模塊兒或者重寫以前的代碼，也不是很困難。
微服務(wù)架構(gòu)模式使得每個(gè)微服務(wù)獨(dú)立部署，且每個(gè)服務(wù)獨(dú)立擴(kuò)展，開發(fā)者不再需要協(xié)調(diào)其它服務(wù)部署對本服務(wù)的影響。微服務(wù)架構(gòu)模式使得持續(xù)化部署成為可能。
2. 從交互上來看，單體應(yīng)用在處理業(yè)務(wù)實(shí)體之間的關(guān)系，直接由框架搞定，如java的hibernate等，而使用微服務(wù)，還要去花時(shí)間去重新整理甚至重構(gòu)業(yè)務(wù)結(jié)構(gòu).首先，在使用框架的同時(shí)，也已經(jīng)受制于框架，甚至是開發(fā)語言的選擇，單體應(yīng)用下，看似方便，可是業(yè)務(wù)實(shí)體之間的關(guān)系太過于固化，當(dāng)有一個(gè)業(yè)務(wù)實(shí)體需要改變，則整個(gè)應(yīng)用相當(dāng)于發(fā)布了一個(gè)新的版本。這種情況對于不care更新停止程序的客戶來說是無所謂，可是對于服務(wù)更新停止程序敏感性比較強(qiáng)甚至不允許停止程序的公司來說，無疑是個(gè)災(zāi)難。所以使用微服務(wù)不是必須的，而是在適當(dāng)?shù)膶?shí)際，架構(gòu)適應(yīng)應(yīng)用場景的一種改變。
3. 微服務(wù)測試起來比較麻煩：首先微服務(wù)根據(jù)不同的業(yè)務(wù)實(shí)體劃分資源服務(wù)，那么也許有些業(yè)務(wù)的操作，會(huì)涉及多個(gè)微服務(wù)，那么測試微服務(wù)的話，就需要將所有的相關(guān)服務(wù)都啟動(dòng)完成，才可以進(jìn)行測試。微服務(wù)測試起來麻煩是沒有任何疑問的，不過微服務(wù)大多采用restful服務(wù)，這為微服務(wù)的測試提供了相對的便利性（測試restful接口的工具還是挺多的）。對于微服務(wù)帶來的便利性，增加這點(diǎn)壓力還是可以容忍的。
4. 微服務(wù)一般對外是restful服務(wù)，為了保證安全性，開銷也是比較大的：一方面服務(wù)內(nèi)部可能每次訪問都需要安全檢查，會(huì)降低效率；另一方面內(nèi)部訪問開啟https，在證書部署維護(hù)方面也會(huì)增加壓力首先，一般微服務(wù)外部都是需要有API GateWay的，由API GateWay來保證外部訪問的安全性，而內(nèi)部訪問，可以省去https和安全檢查，僅保留必要的用戶信息即可。
5. 一般情況下，很多服務(wù)都存在類似session等數(shù)據(jù)存儲(chǔ)在內(nèi)存中，而這些session只在同一WebServer中存在，一般無法進(jìn)行多實(shí)例共享（當(dāng)然也有共享的方案，但是需要相對復(fù)雜的集群設(shè)計(jì)），該如何解決這些數(shù)據(jù)的問題呢？一般情況下，對于絕大部分有狀態(tài)服務(wù)，在設(shè)計(jì)之初，就會(huì)考慮有狀態(tài)服務(wù)的狀態(tài)轉(zhuǎn)移等工作，假設(shè)我們有服務(wù)存在session，那么這些session信息，可以轉(zhuǎn)嫁存儲(chǔ)在一套redis集群中，這樣子就可以多個(gè)實(shí)例都訪問redis，相當(dāng)于狀態(tài)由redis進(jìn)行處理了。
6. 接著上個(gè)問題，微服務(wù)的使用場景中，基本都需要實(shí)現(xiàn)單個(gè)服務(wù)多個(gè)實(shí)例的場景，以實(shí)現(xiàn)高可用，那么問題來了，我對單個(gè)服務(wù)運(yùn)行了10個(gè)實(shí)例，那么該如何知道服務(wù)該向哪個(gè)服務(wù)發(fā)起訪問呢？一般情況下，我們可以使用haproxy之類的服務(wù)，將當(dāng)期服務(wù)的所有實(shí)例進(jìn)行代理，可以先對單個(gè)服務(wù)單點(diǎn)訪問，其他服務(wù)做備份，又可以使用haproxy的負(fù)載均衡，使請求平均分發(fā)到各個(gè)服務(wù)中
7. 接著上個(gè)問題，當(dāng)我運(yùn)行10個(gè)WebServer的時(shí)候，在主機(jī)上需要使用10個(gè)端口進(jìn)行對應(yīng)，而服務(wù)多了以后，對于端口的消耗和管理也是個(gè)比較大的麻煩可以使用docker來解決，在docker的使用中，一個(gè)服務(wù)對應(yīng)一個(gè)鏡像，而基于一個(gè)鏡像可以啟動(dòng)多個(gè)容器，而每個(gè)容器都可以使用統(tǒng)一的內(nèi)部端口，不同的容器名稱，我們使用的haproxy也在docker中運(yùn)行，通過docker內(nèi)部網(wǎng)絡(luò)訪問各個(gè)服務(wù)，這樣就解決了端口問題。
8. 接著上個(gè)問題，一般的應(yīng)用，我們可以使用haproxy來做代理，那么就需要每增加或者修改一次實(shí)例，就需要修改haproxy的配置，管理上的消耗也會(huì)成為比較大的麻煩，并且還有可能出錯(cuò)對于這個(gè)問題，也有解決方案：首先我們可以去嘗試使用如下一套解決方案“docker-swarm-consul-haproxy”，Swarm是一個(gè)用于創(chuàng)建Docker主機(jī)（運(yùn)行Docker守護(hù)進(jìn)程的服務(wù)器）集群的工具,consul用來服務(wù)發(fā)現(xiàn)及配置中心，haproxy則用來進(jìn)行代理服務(wù)
9. 對于眾多的微服務(wù)實(shí)例，服務(wù)較多的至少可以達(dá)到數(shù)百個(gè)甚至數(shù)千個(gè)，監(jiān)控和管理上，也將比較大的挑戰(zhàn)無論是做以往的單體應(yīng)用、SOA還是微服務(wù)，服務(wù)監(jiān)控和管理都是必不可少的，對于監(jiān)控，目前有比較好的容器監(jiān)控開源程序，如：Prometheus、 cAdvisor等；管理方案可以使用簡單的shipyard，復(fù)雜的可以使用kubernetes的
10. 上面提到的很多軟件，都是比較零散的軟件堆疊出來的服務(wù)，有沒有比較好的成套的解決方案？整體的解決方案是有的，就是個(gè)人感覺略重（我個(gè)人搭建的一些服務(wù)，沒有用kubernetes，而是使用了非常簡單compose+swarm）。這個(gè)方案就是使用kubernetes（基于Docker），下面可以簡單描述下我這邊是怎么使用kubernetes來實(shí)現(xiàn)微服務(wù)的：
首選我的微服務(wù)程序都是無狀態(tài)的或者經(jīng)過狀態(tài)轉(zhuǎn)移過的
對于服務(wù)發(fā)現(xiàn)，以往我們用consul，這里我沒有去做服務(wù)發(fā)現(xiàn)和服務(wù)注冊，而是使用kubernetes的ReplicationController來保證我的微服務(wù)實(shí)例數(shù)量（系統(tǒng)會(huì)自動(dòng)維護(hù)）
對外的代理以前用haproxy，而現(xiàn)在使用kubernetes的service來替代，kubernetes自動(dòng)處理各個(gè)微服務(wù)實(shí)例的負(fù)載及請求的分發(fā)，我們只需要保證業(yè)務(wù)穩(wěn)定即可。
by 劉迎光@螢火蟲工作室
OpenBI交流群：495266201
MicroService 微服務(wù)交流群：217722918
mail: liuyg#liuyingguang.cn
博主首頁（==防止爬蟲==）：http://blog.liuyingguang.cn
OpenBI問答社區(qū)：http://www.openbi.tk
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://m.hztianpu.com/yun/26850.html
摘要：故障處理設(shè)計(jì)微服務(wù)架構(gòu)所帶來的一個(gè)后果就是必須考慮每個(gè)服務(wù)的失敗容錯(cuò)機(jī)制。因此，微服務(wù)非常重視建立架構(gòu)及相關(guān)業(yè)務(wù)指標(biāo)的實(shí)時(shí)監(jiān)控和日志機(jī)制。 微服務(wù)架構(gòu)入門 1. 微服務(wù)簡介 微服務(wù)是一種架構(gòu)風(fēng)格，一個(gè)大型的復(fù)雜軟件由一個(gè)或多個(gè)微服務(wù)組成。系統(tǒng)中每個(gè)微服務(wù)都可以被獨(dú)立部署，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成任務(wù)。在所有情況下，每個(gè)任務(wù)代表這一個(gè)小的業(yè)務(wù)能...
摘要：既然這不是宗教，而是關(guān)于如何面對新的事物，我認(rèn)為我們應(yīng)該列出所有其他人認(rèn)為不使用來做開發(fā)的理由。在下工作的不好這是一定的。流行度只是衡量使用率，社區(qū)活躍度的一個(gè)指標(biāo)，用來幫助人們判斷技術(shù)的可用性，穩(wěn)定性和支持程度。不幸的是，人們混淆了和。這是一篇贊美 Ruby 的文章！?。】赐暝賴姴贿t? 請注意：這是一篇主觀意識(shí)的文章。它的目的并不是要說服你使用或者不使用Ruby，或者其他任何技術(shù)。這...
摘要：微服務(wù)常用的進(jìn)程間通信技術(shù)即表述性狀態(tài)傳遞英文，簡稱是博士在年他的博士論文中提出來的一種軟件架構(gòu)風(fēng)格。摘自微服務(wù)實(shí)戰(zhàn)從架構(gòu)到部署處理部分請求失敗對于分布式的微服務(wù)，必須要面對的一大問題就是局部請求失敗的處理。 先拋出幾個(gè)問題 微服務(wù)架構(gòu)的交互模式有哪些？ 微服務(wù)常用的進(jìn)程間通信技術(shù)有哪些？ 如何處理部分請求失敗? API的定義需要注意的事項(xiàng)有哪些 微服務(wù)的通信機(jī)制與SOA的通信機(jī)制之...
摘要：每個(gè)微服務(wù)提供一組，供其他微服務(wù)或者應(yīng)用客戶端所用。由于微服務(wù)架構(gòu)的分布式特點(diǎn)，測試一個(gè)基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)。微服務(wù)架構(gòu)模式下，應(yīng)用的改變將會(huì)波及多個(gè)服務(wù)。 微服務(wù)Microservices已經(jīng)成為軟件架構(gòu)最流行的熱詞之一。網(wǎng)絡(luò)上看到很多關(guān)于微服務(wù)的文章，但是感覺很多離我們還很遙遠(yuǎn)，并且沒有找到多少真正在企業(yè)場景中應(yīng)用的實(shí)例。此處省略一萬字~~~~于是想要將自己最近一段...
閱讀 1944·2021-08-13 15:06
閱讀 3188·2021-08-05 10:02
閱讀 3476·2019-08-30 15:55
閱讀 2473·2019-08-30 13:46
閱讀 2572·2019-08-30 13:01
閱讀 1409·2019-08-29 17:17
閱讀 2891·2019-08-29 15:27
閱讀 1493·2019-08-29 11:12
