国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

微服務指南走北（四）：你不愿意做微服務架構的十個理由

Seay / 1967人閱讀

摘要：微服務架構模式使得每個微服務獨立部署，且每個服務獨立擴展，開發者不再需要協調其它服務部署對本服務的影響。微服務架構模式使得持續化部署成為可能。所以使用微服務不是必須的，而是在適當的實際，架構適應應用場景的一種改變。

近段時間離職，跟同事們講解我之前所做的微服務相關產品，對于同事們提出的問題，做了如下整理出來，加上自己的理解，分享出來跟大家一起探討下：
問題預覽

我為什么要換微服務？能給我帶來什么好處？

從交互上來看，單體應用在處理業務實體之間的關系，直接由框架搞定，如java的hibernate等，而使用微服務，還要去花時間去重新整理甚至重構業務結構.

微服務測試起來比較麻煩：首先微服務根據不同的業務實體劃分資源服務，那么也許有些業務的操作，會涉及多個微服務，那么測試微服務的話，就需要將所有的相關服務都啟動完成，才可以進行測試。

微服務一般對外是restful服務，為了保證安全性，開銷也是比較大的：一方面服務內部可能每次訪問都需要安全檢查，會降低效率；另一方面內部訪問開啟https，在證書部署維護方面也會增加壓力

一般情況下，很多服務都存在類似session等數據存儲在內存中，而這些session只在同一WebServer中存在，一般無法進行多實例共享（當然也有共享的方案，但是需要相對復雜的集群設計），該如何解決這些數據的問題呢？

接著上個問題，微服務的使用場景中，基本都需要實現單個服務多個實例的場景，以實現高可用，那么問題來了，我對單個服務運行了10個實例，那么該如何知道服務該向哪個服務發起訪問呢？

接著上個問題，當我運行10個WebServer的時候，在主機上需要使用10個端口進行對應，而服務多了以后，對于端口的消耗和管理也是個比較大的麻煩

接著上個問題，一般的應用，我們可以使用haproxy來做代理，那么就需要每增加或者修改一次實例，就需要修改haproxy的配置，管理上的消耗也會成為比較大的麻煩，并且還有可能出錯

對于眾多的微服務實例，服務較多的至少可以達到數百個甚至數千個，監控和管理上，也將比較大的挑戰

上面提到的很多軟件，都是比較零散的軟件堆疊出來的服務，有沒有比較好的成套的解決方案？

問題及自己的理解 1. 我為什么要換微服務？能給我帶來什么好處？

可以解決復雜性的問題，在功能不變的情況下，分解為多個相互協作的微服務，通過rest API定義邊界，這樣極大易于開發、理解和維護。

微服務架構是的每個服務可以由專門的開發團隊或者個人開發者進行開發，開發者可以自由選擇技術，不必受制于規定的技術和框架，只要API服務協議好交互方式即可（如restful）。這樣即使重新技術過時的微服務模塊兒或者重寫以前的代碼，也不是很困難。

微服務架構模式使得每個微服務獨立部署，且每個服務獨立擴展，開發者不再需要協調其它服務部署對本服務的影響。微服務架構模式使得持續化部署成為可能。

2. 從交互上來看，單體應用在處理業務實體之間的關系，直接由框架搞定，如java的hibernate等，而使用微服務，還要去花時間去重新整理甚至重構業務結構.

首先，在使用框架的同時，也已經受制于框架，甚至是開發語言的選擇，單體應用下，看似方便，可是業務實體之間的關系太過于固化，當有一個業務實體需要改變，則整個應用相當于發布了一個新的版本。這種情況對于不care更新停止程序的客戶來說是無所謂，可是對于服務更新停止程序敏感性比較強甚至不允許停止程序的公司來說，無疑是個災難。所以使用微服務不是必須的，而是在適當的實際，架構適應應用場景的一種改變。

3. 微服務測試起來比較麻煩：首先微服務根據不同的業務實體劃分資源服務，那么也許有些業務的操作，會涉及多個微服務，那么測試微服務的話，就需要將所有的相關服務都啟動完成，才可以進行測試。

微服務測試起來麻煩是沒有任何疑問的，不過微服務大多采用restful服務，這為微服務的測試提供了相對的便利性（測試restful接口的工具還是挺多的）。對于微服務帶來的便利性，增加這點壓力還是可以容忍的。

4. 微服務一般對外是restful服務，為了保證安全性，開銷也是比較大的：一方面服務內部可能每次訪問都需要安全檢查，會降低效率；另一方面內部訪問開啟https，在證書部署維護方面也會增加壓力

首先，一般微服務外部都是需要有API GateWay的，由API GateWay來保證外部訪問的安全性，而內部訪問，可以省去https和安全檢查，僅保留必要的用戶信息即可。

5. 一般情況下，很多服務都存在類似session等數據存儲在內存中，而這些session只在同一WebServer中存在，一般無法進行多實例共享（當然也有共享的方案，但是需要相對復雜的集群設計），該如何解決這些數據的問題呢？

一般情況下，對于絕大部分有狀態服務，在設計之初，就會考慮有狀態服務的狀態轉移等工作，假設我們有服務存在session，那么這些session信息，可以轉嫁存儲在一套redis集群中，這樣子就可以多個實例都訪問redis，相當于狀態由redis進行處理了。

6. 接著上個問題，微服務的使用場景中，基本都需要實現單個服務多個實例的場景，以實現高可用，那么問題來了，我對單個服務運行了10個實例，那么該如何知道服務該向哪個服務發起訪問呢？

一般情況下，我們可以使用haproxy之類的服務，將當期服務的所有實例進行代理，可以先對單個服務單點訪問，其他服務做備份，又可以使用haproxy的負載均衡，使請求平均分發到各個服務中

7. 接著上個問題，當我運行10個WebServer的時候，在主機上需要使用10個端口進行對應，而服務多了以后，對于端口的消耗和管理也是個比較大的麻煩

可以使用docker來解決，在docker的使用中，一個服務對應一個鏡像，而基于一個鏡像可以啟動多個容器，而每個容器都可以使用統一的內部端口，不同的容器名稱，我們使用的haproxy也在docker中運行，通過docker內部網絡訪問各個服務，這樣就解決了端口問題。

8. 接著上個問題，一般的應用，我們可以使用haproxy來做代理，那么就需要每增加或者修改一次實例，就需要修改haproxy的配置，管理上的消耗也會成為比較大的麻煩，并且還有可能出錯

對于這個問題，也有解決方案：首先我們可以去嘗試使用如下一套解決方案“docker-swarm-consul-haproxy”，Swarm是一個用于創建Docker主機（運行Docker守護進程的服務器）集群的工具,consul用來服務發現及配置中心，haproxy則用來進行代理服務

9. 對于眾多的微服務實例，服務較多的至少可以達到數百個甚至數千個，監控和管理上，也將比較大的挑戰

無論是做以往的單體應用、SOA還是微服務，服務監控和管理都是必不可少的，對于監控，目前有比較好的容器監控開源程序，如：Prometheus、 cAdvisor等；管理方案可以使用簡單的shipyard，復雜的可以使用kubernetes的

10. 上面提到的很多軟件，都是比較零散的軟件堆疊出來的服務，有沒有比較好的成套的解決方案？

整體的解決方案是有的，就是個人感覺略重（我個人搭建的一些服務，沒有用kubernetes，而是使用了非常簡單compose+swarm）。這個方案就是使用kubernetes（基于Docker），下面可以簡單描述下我這邊是怎么使用kubernetes來實現微服務的：

首選我的微服務程序都是無狀態的或者經過狀態轉移過的

對于服務發現，以往我們用consul，這里我沒有去做服務發現和服務注冊，而是使用kubernetes的ReplicationController來保證我的微服務實例數量（系統會自動維護）

對外的代理以前用haproxy，而現在使用kubernetes的service來替代，kubernetes自動處理各個微服務實例的負載及請求的分發，我們只需要保證業務穩定即可。

by 劉迎光@螢火蟲工作室  
OpenBI交流群：495266201  
MicroService 微服務交流群：217722918    
mail: liuyg#liuyingguang.cn  
博主首頁（==防止爬蟲==）：http://blog.liuyingguang.cn  
OpenBI問答社區：http://www.openbi.tk

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/26850.html

相關文章

  • 微服務架構入門

    摘要：故障處理設計微服務架構所帶來的一個后果就是必須考慮每個服務的失敗容錯機制。因此，微服務非常重視建立架構及相關業務指標的實時監控和日志機制。 微服務架構入門 1. 微服務簡介 微服務是一種架構風格，一個大型的復雜軟件由一個或多個微服務組成。系統中每個微服務都可以被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成任務。在所有情況下，每個任務代表這一個小的業務能...

    ninefive 評論0 收藏0

  • 不使用Ruby的十個理由

    摘要：既然這不是宗教，而是關于如何面對新的事物，我認為我們應該列出所有其他人認為不使用來做開發的理由。在下工作的不好這是一定的。流行度只是衡量使用率，社區活躍度的一個指標，用來幫助人們判斷技術的可用性，穩定性和支持程度。不幸的是，人們混淆了和。這是一篇贊美 Ruby 的文章！！！看完再噴不遲? 請注意：這是一篇主觀意識的文章。它的目的并不是要說服你使用或者不使用Ruby，或者其他任何技術。這...

    young.li 評論0 收藏0

  • 微服務指南走北（二）：微服務架構的進程間通信（IPC）

    摘要：微服務常用的進程間通信技術即表述性狀態傳遞英文，簡稱是博士在年他的博士論文中提出來的一種軟件架構風格。摘自微服務實戰從架構到部署處理部分請求失敗對于分布式的微服務，必須要面對的一大問題就是局部請求失敗的處理。 先拋出幾個問題 微服務架構的交互模式有哪些？ 微服務常用的進程間通信技術有哪些？ 如何處理部分請求失敗? API的定義需要注意的事項有哪些 微服務的通信機制與SOA的通信機制之...

    beanlam 評論0 收藏0

  • 微服務指南走北（一）：微服務是什么

    摘要：每個微服務提供一組，供其他微服務或者應用客戶端所用。由于微服務架構的分布式特點，測試一個基于微服務架構的應用也是很復雜的任務。微服務架構模式下，應用的改變將會波及多個服務。 微服務Microservices已經成為軟件架構最流行的熱詞之一。網絡上看到很多關于微服務的文章，但是感覺很多離我們還很遙遠，并且沒有找到多少真正在企業場景中應用的實例。此處省略一萬字~~~~于是想要將自己最近一段...

    sherlock221 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<