微服務運維

1. 最近去聽講座，有說微服務引擎挺火的，什麼是微服務引擎

微服務引擎(Cloud Service Engine) 提供高性能微服務框架和一站式服務注冊、服務治理、動態配置和分內布式事務管理控制台，幫容助用戶實現微服務應用的快速開發和高可用運維。 據了解華為的微服務引擎和微服務應用都有做，在性能、開放兼容上強於SpringCloud和HSF，但是在其他的功能完備上各有優劣吧。

2. 為什麼說微服務的運維不可缺少DevOps

微服務的概念產生是順應這樣的需求：為了開發出速度更快、更有彈性且用戶體驗更佳的應用。這個概念等同於具有可擴展性的自動化系統，在簡單的商業化架構上運行軟體。

3. 網站微服務是什麼意思呢

微服務得從兩個方面去理解，什麼是"微"、什麼是"服務"， 微 狹義來講就是體積小、著名的"2 pizza 團隊"很好內的詮釋了這一解釋容（2 pizza 團隊最早是亞馬遜 CEO Bezos提出來的，意思是說單個服務的設計，所有參與人從設計、開發、測試、運維所有人加起來 只需要2個披薩就夠了 ）。 而所謂服務，一定要區別於系統，服務一個或者一組相對較小且獨立的功能單元，是用戶可以感知最小功能集。

4. 什麼是微服務架構啊

微服務架構其實沒有一個非常准確的定義，大概描述的是一個大型復專雜軟體應用系統由若屬干個微服務組成。系統中的各個微服務能被獨立部署和擴展，每個微服務還能提供一個穩固的模塊邊界。各個微服務之間是松耦合的，微服務很小，專注於做好一件事情。微服務框架帶了良好的技術異構性、彈性、擴展性，它的簡化部署為持續交付提供了巨大推動力。但是它同時也帶來一些挑戰，比如分布式事務一致性，網路性能消耗等問題。所以選用的時候要結合實際業務考慮，若想深入學習的話建議使用些現成的一些大廠商開源的微服務框架開發試試手，用一用spring cloud、servicecomb，網上資料都很多，希望這個回答對你有幫助。

5. 如何提高微服務架構的可用性

【編者的話】有些開發者可能還是不明白Docker對自己到底有多大的用處，因此翻譯Docker個人用例這篇文章中來介紹Docker在普通開發者開發過程中的用例。Docker如今贏得了許多關注，很多人覺得盛名之下其實難副，因為他們仍然搞不清Docker和普通開發者到底有什麼關系。許多開發者覺得Docker離自己很遠，Docker是生產環境中的工具，和自己無關。我也是花了很長時間才想清楚作為普通開發人員如何在自己的開發中使用Docker。坦率地說，我仍處在學習的過程中。這篇文章提供了一個Docker用例列表，我希望它能更好地幫助你理解Docker並引發你的思考。本文只是描述Docker在普通開發者日常的應用，並不提供完整的解決方案。在介紹用例之前，我希望你能先記住這句話：「Docker是一個便攜的應用容器」。你可以不知道Docker所說的的「攜帶型容器」到底是什麼意思，但是你必須清楚Docker在日常中能帶來非常大的效率提升。當你需要在容器內運行自己的應用（當然可以是任何應用），Docker都提供了一個基礎系統鏡像作為運行應用時的基礎系統。也就是說，只要是Linux系統上的應用都可以運行在Docker中。可以在Docker裡面運行資料庫嗎？當然可以。可以在Docker裡面運行Node.js網站伺服器嗎？當然可以。可以在Docker裡面運行API伺服器嗎？當然可以。Docker並不在乎你的應用程序是什麼、做什麼，Docker提供了一組應用打包、傳輸和部署的方法，以便你能更好地在容器內運行任何應用。下面的例子我自己經常使用，當然你有更好的案例也可以分享給我。嘗試新軟體對開發者而言，每天會催生出的各式各樣的新技術都需要嘗試，然而開發者卻不太可能為他們一一搭建好環境並進行測試。時間非常寶貴，正是得益於Docker，讓我們有可能在一條或者幾條命令內就搭建完環境。Docker有一個傻瓜化的獲取軟體的方法，Docker後台會自動獲得環境鏡像並且運行環境。並不僅僅是新技術環境搭建用得到Docker。如果你想快速在你的筆記本上運行一個MySQL資料庫，或者一個Redis消息隊列，那麼使用Docker便可以非常容易地做到。例如Docker只需要一條命令便可以運行MySQL資料庫：dockerrun-d-p3306:3306tutum/mysql。譯者註：雖然使用命令也能非常快地安裝MySQL資料庫，但是當用到最新的技術或者非常復雜的技術時，使用Docker便會是個非常好的選擇，例如Gitlab，普通用戶大概需要一天的時間去搭建Gitlab平台，而Docker則只需要一條命令。進行演示現在我經常需要在周末用自己開發的成果對客戶活著別人做一兩個演示。搭建演示環境的過程非常麻煩。現在我發現Docker已經成為我演示這些工具的最合理的方式。同時，對於客戶來說，我可以直接將Docker鏡像提供給他們，而不必去做任何環境配置的工作，工作的效果也會和在他們演示中所看到的一模一樣，同時不必擔心他們的環境配置會導致我們的產品無法運行。避免「我機器上可以運行」無論是上一篇介紹的企業部署Docker還是本文的個人Docker用例，都提到了這個情況。因為環境配置不同，很多人在開發中也會遇到這個情況，甚至開發的軟體到了測試人員的機器上便不能運行。但這都不是重點。重點是，如果我們有一個可靠的、可分發的標准開發環境，那麼我們的開發將不會像現在這么痛苦。Docker便可以解決這個問題。Docker鏡像並不會因為環境的變化而不能運行，也不會在不同的電腦上有不同的運行結果。可以給測試人員提交含有應用的Docker鏡像，這樣便不再會發生「在我機器上是可以運行的」這種事情，很大程度上減輕了開發人員測試人員互相檢查機器環境設置帶來的時間成本。另一個Docker可以發揮用處的地方是培訓班。除了Docker容器的隔離性之外，更能體會到Docker優勢的地方在於環境搭建。培訓班的新手每個人都要在環境搭建上花費很多時間，但是如果在這里應用到Docker的話，那麼我們只需要把標準的運行環境鏡像分發下去，然後就可以開始上課了。使用Docker和使用虛擬機一樣簡單，但是Docker要更方便、更輕量級。同時，我們也可以告訴學員：「在培訓的同時，我們還將學到當下最流行的技術——Docker」，這種雙贏的結局，何樂而不為呢。學習Linux腳本當然這個原因看起來可能很奇怪，但是對不不熟悉Linux操作系統和Shell腳本的人來說，確實是一個好機會。即便本文並不是在講Linux，Linux的重要度仍然不言而喻。如果你用的是Windows，那麼我給你一個建議：從雲主機提供商那兒租用一台雲主機：我推薦使用CoreOS系統的雲主機。雖然這樣並不會讓你成為專業的Linux運維，但是可以讓你快速地學到Linux基礎知識，愛上命令行操作，並且慢慢開始熟悉和欣賞Linux。更好地利用資源虛擬機的粒度是「虛擬出的機器」，而Docker的粒度則是「被限制的應用」，相比較而言Docker的內存佔用更少，更加輕量級。對我來說這是Docker的一個優勢：因為我經常在自己電腦中運行多個Docker應用，使用Docker比使用虛擬機更加簡單，方便，粒度更細，也能持續地跟蹤容器狀態。為微服務定製如果你一直在關注科技新聞的話，那麼你應該聽說過「微服務（Microservices）」的概念。Docker可以很好地和微服務結合起來。從概念上來說，一個微服務便是一個提供一整套應用程序的部分功能，Docker便可以在開發、測試和部署過程中一直充當微服務的容器。甚至生產環境也可以在Docker中部署微服務。在雲服務提供商之間移植大多數的雲主機提供商已經全面支持Docker。對於開發人員來說，這表示你可以很方便地切換雲服務提供商，當然也可以很方便地將你本地的開發環境移動到雲主機上，不需要本地上配置一次運行環境、在雲主機上還配置一次運行環境。全面部署Docker(DockerhereandDockerthere)作為標准運行環境可以極大地減輕應用上線時的工作量和產生BUG。

6. 微服務,一個服務會影響整個系統嗎

摘要： 最近大家都在談微服務，隨著越來越多的在線業務需要提供更大並發的scale-up 和 scale out能力，微服務確實提供了比較好分布式服務的解決方案。

阿里雲高級解決方案架構師 楊旭

世界最大混合雲的總架構師，4年前，開始作為雙11阿里雲技術負責人，負責搭建全球最大的混合雲結構，把 「雙11」的電商業務和技術場景在阿里雲上實現，並保障這個混合雲在雙11當天能夠滿足全球客戶的購物需求。

正文：

最近大家都在談微服務，隨著越來越多的在線業務需要提供更大並發的scale-up 和 scale out能力，微服務確實提供了比較好分布式服務的解決方案。

微服務並不陌生，知道SOA其實也就很容易理解微服務，可以把微服務當做去除了ESB的SOA。ESB是SOA企業服務架構中的匯流排，而微服務是去中心化的分布式軟體架構，個人認為最大的設計區別在於設計初衷：

SOA是為了最大化的實現復雜系統代碼的可復用性
而微服務是為了最大限度的解耦，不同業務系統甚至可以是不同語言之間的通信
沒有最優的架構，只有最合適的架構，一切系統設計原則都要以解決業務問題為最終目標，脫離實際業務的技術情懷架構往往會給系統帶入大坑。所有問題的前提要搞清楚我們今天面臨的業務量有多大，增長走勢是什麼樣，而且解決高並發的過程，一定是一個循序漸進逐步的過程。

網上的一張圖很經典，總結的非常好：

整個系統進化分為三個階段：

x軸，水平擴展階段，通過負載均衡伺服器不斷的橫向擴充應用伺服器，水平擴展最重要的問題是需要注意不用伺服器之間的如何保持session和會話同步，不能讓用戶在不通伺服器之間切換時有感知應用擴展後自然遇到的問題就是DB的瓶頸：連接數，iops等。

z軸，就是對資料庫的拆分，難度上了一個台階，Sharding的基本思想就要把一個資料庫如何進行切分，可以分為水平切分和垂直切分，水平切分相對簡單，一主多從，多主都可以，根據業務的需要，多主切分設計時需要注意主鍵的關系，解決多寫在進行數據同步時候的沖突問題，垂直拆分更加復雜，一般都會涉及到架構邏輯的改造，需要引入中間件，來進行數據源的管理，垂直拆分時把關系緊密（比如同一模塊）的表切分出來放在一個庫上，或者通過hash進行拆分，從而將原有資料庫切分成類似矩陣一樣可以無限擴充的隊列。

y軸擴展，最後就是功能分解了，也就是我們講的微服務切分。微服務拆分將巨型應用按照功能模塊分解為一組組不同的服務，淘寶的系統當年也經歷了這樣的過程，通過五彩石項目從單一的war包拆分成了今天的大家看到買家，賣家中心，交易等系統。

引入微服務前你要知道的兩三事：

1、成本升高，引入微服務架構，需要對原來單一系統進行拆分，1到100以後多服務的部署會帶來成本的升高

2、解決分布式事務一致性問題

以前單一的系統好處很多，一條sql解決完成所有業務邏輯，微服務做完一件事情需要涉及多系統調用，系統間網路的不確定性給結果帶來很多不確定性，如今天淘寶的系統，完成一次交易下單需要在上百個系統之間調用，如何保證系統的可靠性，以及核心數據如錢的最終一致性是設計之初就要想明白的，這里大多都要藉助中間件來實現。

3、微服務的邏輯設計原則

隨著不斷拆分微服務，以及業務的迭代發展，系統之間極有可能出現混亂調用，所以微服務的頂層設計顯得尤為重要，架構師需要搞清楚微服務的架構模型。那核心的設計思想就在於如何進行服務的分層，以及服務的重用，通過分層將服務進行分配，上層服務包裝下層服務，下層服務負責原子性的操作，上層服務對下層服務進行業務性的組合編排，一定要理解業務，微服務拆分不是簡單的系統組合，再說一遍一定要理解業務，否則上層服務一定會出現大量的交叉調用，系統復雜度會指數級上升，好的微服務架構師一定是業務架構師，基於業務的建瓴，微服務設計三部曲，遵循自下而上的設計原則：

原子服務

首先確認最基本業務最維度的原子服務，原子服務定義就是大家都會最大化重用的功能，需要在應用內的閉環操作，沒有任何跨其他服務的分支邏輯，杜絕對其他服務的調用，有自己獨立的數據存儲，作為最底層服務抽象存在，以淘寶為例，賣家數據，賣家數據，訂單數據就屬於最基本的原子服務。

服務組合

在業務場景下，一個功能都需要跨越多個原子服務來完成一個動作。組合服務就是將業務邏輯抽象拆成獨立自主的域，域之間需要保持隔離，服務組合會使用到多個原子服務來完成業務邏輯，如淘寶的交易平台會調用用戶，商品，庫存等系統。

業務編排

最外層就是面向用戶的業務流程，一個產品化的商業流程需要對組合服務進行邏輯編排來完成最終的業務結果，這個編排服務可以完全是自動化的，通過工作流引擎進行組合自動化來完成特定SOP定義，這對企業應用的自動化流程改進也很有意義。如淘寶類目的雙十一活動，通過對不通服務組合進行重用實現不通的營銷活動邏輯。

4、運維管理的復雜度提升

微服務讓應用數量增加很多，鏈路的集成、測試、部署都成為新的挑戰，以前一個war包解決的問題，需要通過多應用發布來完成，發布時服務之間的依賴影響，會導致功能不可用，測試階段的依賴性可能會讓用例跑不下去，這些都會是需要新考慮的問題，需要有平台化的工具來支撐，目前阿里通過aone產品來保證從日常到預發到線上的持續集成交付。

7. 如何在微服務架構下構建高效的運維管理平台

找一家專業的運維服務公司，選擇一個適合自己的運維管理平台，你要是比較重視專知識積累，那你屬就選擇一個知識庫功能強大的；如果你更在意流程的高效便捷性，那就要選擇一個流程管理強的，其他類似於監控、巡檢、預警、等等功能，現在已經成為運維管理平台的基本功能了。
這個你了解一下 雲雀運維，性價比很高，功能全面。

8. 微服務都是用在什麼地方能否舉例說明一下

隨著移動互聯網的發展和應用雲化的普及，微服務已經成為企業應用服務化架構最流行的設計理念。以微服務、容器、DevOps等為支撐的雲原生設計理念，緩解了隨著新需求的不斷增加，大型單體式應用變更越來越困難的現狀，與移動互聯網時代下對企業IT架構高效穩定、敏捷響應的要求之間的矛盾。
「Nebulogy納比雲」提供完整的微服務實施平台及賦能工具，加速微服務應用開發和DevOps持續交付，為雲應用的構建和運行支撐提供有力的支持。微服務實施方案

9. SOA和微服務架構的區別

SOA與微服務架構，在架構劃分、技術平台選擇等方面，均存在一定的區別。

一、架構劃分不同

1、SOA強調按水平架構劃分為：前、後端、資料庫、測試等；

2、微服務強調按垂直架構劃分，按業務能力劃分，每個服務完成一種特定的功能，服務即產品。

二、技術平台選擇不同

1、SOA應用傾向於使用統一的技術平台來解決所有問題；

2、微服務可以針對不同業務特徵選擇不同技術平台，去中心統一化，發揮各種技術平台的特長。

三、系統間邊界處理機制不同

1、SOA架構強調的是異構系統之間的通信和解耦合；（一種粗粒度、松耦合的服務架構）；

2、微服務架構強調的是系統按業務邊界做細粒度的拆分和部署。

四、主要目標不同

1、SOA架構，主要目標是確保應用能夠交互操作；

2、微服務架構，主要目標是實現新功能、並可以快速拓展開發團隊。

參考資料

網路-SOA

網路-微服務架構

10. 微服務主要用在什麼場景

微服務是一種架構方式，如果是快速部署、便捷維護、安全上雲，可以選擇黑少微服務，我覺得很方便。