close
本文作者最近分析瞭一些 MongoDB 的性能問題，發現 MongoDB 自帶的 Explain 有很強大的分析功能。根據 Explain 的運行結果可以得到 find 語句執行過程中每一個步驟的執行時間以及掃描 Document 所使用得索引細節。作者將根據幾個具體的場景來分析如何利用 explain 瞭解語句執行的效率，如何通過創建索引提高 find 語句的性能。
作為一名工程師，我可以理解大傢的心情，我們都是熱愛嘗試新技術、拋棄過時技術的人。但是首先得明確，到底技術是不是過時的，還是僅僅是你認為它過時瞭。這篇文章我想談談我對技術選型的理解。 這篇文章不僅僅是寫給工程師，更多是寫給技術團隊負責人（大多數也是從工程師升職上去的，起初思維和工程師差距不大），因為你們具體負責技術選型的方向、方法、過程、結論明確。
本期主要內容：構建商業AI能力的五大要素；判別AI改造企業的70個指標；用最小成本 驗證AI可行性；企業技術人員如何向人工智能靠攏？打造基於機器學習的推薦系統；打造機器學習的基礎架構平臺；如何解決特征工程；人工智能的下一個技術風口與商業風口。
《SAFe Distilled》一書將復雜的框架分解成易於理解的解釋和可操作的指南，從中我們可以深入理解及學習如何實現“大規模敏捷框架（Scaled Agile Framework）”。
從構建階段到傳輸至生產運行階段，容器在每個階段都面臨著安全風險。容器防護需要在整個棧及部署過程中引入一種分層安全策略。
雖然已經紅瞭很久，但是“微服務架構”正變得越來越重要，也將繼續火下去。
各個公司與技術人員都在分享微服務架構的相關知識與實踐經驗，但我們發現，目前網上的這些相關文章中，要麼上來就是很有借鑒意義的幹貨，要麼就是以高端的專業術語來講述何為微服務架構。就是沒有一個做到成熟地將技術傳播出來，同時完美地照顧“初入微服務領域人員”，從0開始，采用通俗易懂的語言去講解微服務架構的系列。
所以，我們邀請青柳雲的蘇槐與InfoQ一起共建微服務架構專題“Re：從0開始的微服務架構”，為還沒有入門該領域的技術人員開路，也幫助微服務架構老手溫故知新。
得益於2013年Docker的誕生，微服務概念及架構的推廣和落地變得更加的可靠和方便。在2016年及之前，微服務架構的討論更多的是活躍於互聯網企業及社區。現如今，隨著Docker和微服務架構組件與Docker等相關技術的逐步成熟，微服務架構已然步入傳統企業及傳統行業。
但是，程序員作為一個理性消費的群體，需要冷靜地思考，避免挖個大坑把自己給埋瞭。所以，我們需要冷靜地搞清楚：微服務（架構）是什麼？它有什麼優勢劣勢？我們為什麼需要采用微服務架構？如何讓老板接受這一新技術？如何落地？如何升級維護？等等……
我們在過去7年智慧城市的建設過程中，研發和交付瞭很多的大型項目，踩過很多的坑，趟過很多的雷，深受傳統建設方法之苦，也深深被微服務架構帶來的好處所感動，我們也將在微服務架構這條路的繼續前行。在這裡，將我們研發過程中的一些思考和心得分享給大傢，供大傢參考。
也許，在不久的將來，軟件開發隻需要組裝，不再需要從頭開發。
(點擊放大圖像)
什麼是微服務架台中產後護理機構構？
形像一點來說，微服務架構就像搭積木，每個微服務都是一個零件，並使用這些零件組裝出不同的形狀。通俗來說，微服務架構就是把一個大系統按業務功能分解成多個職責單一的小系統，並利用簡單的方法使多個小系統相互協作，組合成一個大系統。
如果學科派一點，微服務架構就是把因相同原因而變化的功能聚合到一起，而把因不同原因而變化的功能分離開，並利用輕量化機制（通常為HTTP RESTful API）實現通信。
追本溯源，Martin Folwer對微服務架構的定義是：
(點擊放大圖像)
微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相協作（通常是基於HTTP協議的RESTful API）。每個服務都圍繞著具體業務進行構建，並且能夠被獨立的部署到生產環境、類生產環境等。另外，對具體的服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建 。（摘自王磊先生的《微服務架構與實踐》）
對於我個人，我更喜歡一種延續性的解釋，微服務架構 ≈ 模塊化開發 + 分佈式計算。不管微服務架構的定義怎麼樣，都是在描述一個核心思想：把大系統拆分成小型系統，把大事化小，以降低系統的復雜性，從而大幅降低系統建設、升級、運維的風險和成本。
順帶提一下，亞馬遜創始人Jeff Bezos在2002年就說過：所有團隊的模塊都要以Service Interface的方式將數據和功能開放出來。不這樣做的人會被炒魷魚。這才是思路超前的大牛。
(點擊放大圖像)
需要註意的是“微服務”與“微服務架構”是有本質區別的。“微服務”強調的是服務的大小，它關註的是某一個點。而“微服務架構”則是一種架構思想，需要從整體上對軟件系統進行通盤的考慮。
Chris Richardson說：“微服務”是一個很糟糕的名字，它導致開發人員創建瞭許多粒度很小的服務，每個服務擁有一個單獨的REST端點。不僅如此，這個名字還暗示瞭微服務在開發者心目中的重要位置。例如，人們會說“我們可以用微服務來解決這個問題”；我也看到瞭越來越多的“某某微服務框架”，而實際上，這些框架跟微服務架構不一定有太多聯系，它們隻是簡單的Web框架。使用“微服務架構”這個名字會更恰當些。它是一種架構風格，它把一系列協作的服務組織成一個系統來支撐業務。
常見的微服務組件及概念
服務註冊，服務提供方將自己調用地址註冊到服務註冊中心，讓服務調用方能夠方便地找到自己。
服務發現，服務調用方從服務註冊中心找到自己需要調用的服務的地址。
負載均衡，服務提供方一般以多實例的形式提供服務，負載均衡功能能夠讓服務調用方連接到合適的服務節點。並且，節點選擇的工作對服務調用方來說是透明的。
服務網關，服務網關是服務調用的唯一入口，可以在這個組件是實現用戶鑒權、動態路由、灰度發佈、A/B測試、負載限流等功能。
配置中心，將本地化的配置信息（properties, xml, yaml等）註冊到配置中心，實現程序包在開發、測試、生產環境的無差別性，方便程序包的遷移。
API管理，以方便的形式編寫及更新API文檔，並以方便的形式供調用者查看和測試。
集成框架，微服務組件都以職責單一的程序包對外提供服務，集成框架以配置的形式將所有微服務組件（特別是管理端組件）集成到統一的界面框架下，讓用戶能夠在統一的界面中使用系統。
分佈式事務，對於重要的業務，需要通過分佈式事務技術（TCC、高可用消息服務、最大努力通知）保證數據的一致性。
調用鏈，記錄完成一個業務邏輯時調用到的微服務，並將這種串行或並行的調用關系展示出來。在系統出錯時，可以方便地找到出錯點。
支撐平臺，系統微服務化後，系統變得更加碎片化，系統的部署、運維、監控等都比單體架構更加復雜，那麼，就需要將大部分的工作自動化。現在，可以通過Docker等工具來中和這些微服務架構帶來的弊端。 例如持續集成、藍綠發佈、健康檢查、性能健康等等。嚴重點，以我們兩年的實踐經驗，可以這麼說，如果沒有合適的支撐平臺或工具，就不要使用微服務架構。
一般情況下，如果希望快速台中月子中心比較地體會微服務架構帶來的好處，使用Spring Cloud提供的服務註冊（Eureka）、服務發現（Ribbon）、服務網關（Zuul）三個組件即可以快速入門。其它組件則需要根據自身的業務選擇性使用。
微服務架構有哪些優勢劣勢？
要談優勢，就一定要有對比，我們可以嘗試著從兩個維度來對比。
一、微服務架構與單體架構的對比
早期設計和溝通的工作量加大，隨著項目規模和時間的推移，效率變化不大
早期工作量小，隨著項目規模和時間的推移，效率大幅度下降
單體架構勝
開發效率（復雜項目）
早期設計和溝通的工作量加大，隨著項目規模和時間的推移，效率變化不大
早期工作量小，隨著項目規模和時間的推移，效率大幅度下降
微服務架構勝
系統設計（高內聚低耦合）
每個業務單獨包裝成一個微服務，數據和代碼都從物理上隔離開來，實現高內聚低耦合相對容易
以包的形式對代碼進行模塊劃分，控制得當即可實現高內聚。但最終都是在數據層面將整個系統耦合在一起
微服務架構勝
系統設計（擴展性）
獨立開發新模塊，通過API與現有模塊交互
在現有系統上修改，與現存業務邏輯高度耦合
微服務架構勝
需求變更響應速度
各個微服務組件獨立變更，容易實施敏捷開發方法
需要瞭解整個系統才可以正確修改，容易導致不相關模塊的意外失敗
微服務架構勝
系統升級效率
各個微服台中月子中心價錢務組件獨立升級，上手和開發效率高，影響面小
需要瞭解整個系統才可以正確修改，容易導致不相關模塊的意外失敗
微服務架構勝
大系統被拆分為多個小系統，部署和運維難度加大，但可以利用DevOps等方式將運維工作自動化
單體架構勝
微服務組件可以在新項目中直接復用，包括前端頁面
一般以共享庫的形式復用後臺代碼
微服務架構勝
硬件需求（簡單項目）
一個系統需部署多個微服務，需要啟動多個運行容器
整個系統隻需要一個運行容器
單體架構勝
硬件需求（高要求項目）
按需為不同業務模塊伸縮資源節點
為整個系統分配資源，導致冗餘
微服務架構勝
項目成本（簡單系統）
項目早期和後期，成本變化曲線平緩
項目早期成本低，後期成本大
單體架構勝
項目成本（復雜系統）
項目早期和後期，成本變化曲線平緩
項目早期成本低，後期成本大
微服務架構勝
非功能需求
為單獨的微服務按需調優，甚至更換實現方式和程序語言
為整個系台中產後護理中心介紹統調優，牽一發而動全身
微服務架構勝
職責、成就感
擁有明確的職責劃分，主人翁意識和成就感加強，容易形成自組織型團隊
職責不明確，容易產生扯皮行為
微服務架構勝
大系統被拆分為小系統，風險可被控制在小系統內，但也引入瞭各小系統之間的交互風險
系統是一個整體，一榮俱榮，一損俱損
微服務架構勝
結論:
對於簡單項目來說，單體架構5勝8敗。（優勢項：開發效率、上手難度、運維效率、硬件需求、項目成本；劣勢項：系統設計（高內聚低耦合）、系統設計（擴展性）、需求變更響應速度、系統升級效率、知識積累、非功能需求、職責、成就感、風險）
對於復雜項目來說，單體架構2勝11敗。（優勢項：上手難度、運維效率；劣勢項：硬件需求、項目成本、開發效率、系統設計（高內聚低耦合）、系統設計（擴展性）、需求變更響應速度、系統升級效率、知識積累、非功能需求、職責、成就感、風險；）
二、微服務與共享庫的對比
註：這裡以使用方自行安裝微服務為場景來比較。這裡的共享庫指的是像Java中的公共jar依賴。
微服務為完整的業務邏輯單元，通過API的形式為其它模塊提供服務
在使用方的源代碼中引用共享庫的類和方法
單獨升級，其它模塊無感知
修改源代碼，升級使用方的代碼版本，例如pom.xml, build.gradle
微服務架構勝
Bug修復
單獨升級，自動生效
修改源代碼，升級使用方的代碼版本，例如pom.xml, build.gradle
微服務架構勝
非功能需求
為單獨的微服務優化或擴縮容；在需求更高的情況下，可以重新設計或使用不同的程序語言
為整個業務系統優化或擴縮容，共享庫的程序語言必須和業務系統的程序語言相同
微服務架構勝
可以復用從前端頁面到後臺數據庫的整個業務邏輯和代碼
可以復用後臺代碼和數據庫，但程序語言需要和業務系統保持一致
微服務架構勝
什麼場景需要用微服務架構？
看瞭上面的比較，微服務架構可以說是以壓倒性的優勢勝過單體架構和共享庫，會讓人產生一種錯覺，微服務架構就是軟件開發中的銀彈。
但是，正如大傢所瞭解的，軟件研發是一個系統工程，它沒有銀彈，不能夠一招鮮吃遍天。正如當年的CMMI和敏捷方法一樣，敏捷雖好，但它不一定能適用於所有的場景，它對組織環境、團隊氛圍、溝通方式、技術能力這些都是有一些要求的，如果用不好，反而會帶來一些負面影響。
那麼，我們什麼時候需要采用微服務呢？從我個人的經驗來看，我認為有三種場景可以考慮使用微服務。
規模大（團隊超過10人）
業務復雜度高（系統超過5個子模塊）
需要長期演進（項目開發和維護周期超過半年）
這裡借一張圖來說明:
(點擊放大圖像)
橫軸是復雜度，縱軸是生產效率。從生產效率的角度來講，在兩條曲線的交叉點之前，單體架構是占優勢的，過瞭交叉點之後，單體架構的生產效率將大幅度下降。
所以很多專傢和同行朋友都說，我們可以在開始的時候先使用單體架構，當業務發展到一定程度的時候，再重構成微服務架構。對於這一點，我是持保留意見的，因為在實踐中，架構改造的難度還是很大的，會有一些問題，例台中產後護理中心推薦如:
客戶或業務部門是否給我們這樣的時間窗口？
這段時間的研發經費是否有出處？
項目負責人或技術團隊是否有主動的意願進行架構升級？
項目負責人或技術團隊是否願意為架構升級帶來的不穩定風險負責？
我們常常聽到的一句話是：暫時先這樣，等我們沒這麼忙的時候，再來優化一下。但是，絕大多數情況下，這一天從來沒有出現過。
再想想年初，我們的私有雲平臺經過2年多的發展，已經包含瞭容器服務平臺（PaaS）、API網關、監控平臺、定時任務平臺、數據庫管理、用戶權限管理等等十多個基礎模塊，也包含瞭一些為上層應用服務提供的日志服務、緩存服務、消息服務等等。並且，部署到瞭二十多個客戶的生產環境裡。可悲的是，我們支撐瞭很多的業務系統的微服務化，但平臺本身任然是一個單體系統。
我們也深深地感受到瞭平臺往前發展的阻力：
很多時候，客戶需要的不是一個大而全的平臺，他們希望按他們的意願采購需要的模塊。
新人進入團隊後，從熟悉到動手產出的時間偏長。
其它研發團隊有一些比較好的組件能滿足平臺產品的需求，卻不能直接拿來用。
兩個不同的模塊之間產生瞭不該出現的耦合關系，導致意想不到的Bug。
所以，春節過後，大傢開瞭一個會，決定將平臺微服務化。而帶來的代價就是要說服老板給我們兩個月時間來重構。
幸運的是，我們很快得到瞭老板的支持，並且重構工作比較順利；不幸的是，那二十多個客戶的生產環境的升級非常麻煩，每升級一個客戶都得花上一周左右的時間，至今也才升級瞭一小部分。
所以，理想的情況下，我建議在項目初期的時候就從上面提到的三點做好評估，到底采用哪種架構形式是符合項目具體情況的。
當然，如果真的有朋友想將歷史悠久的單體架構升級到微服務架構，我建議先從邊緣邏輯開始，逐步逐步地將業務邏輯從單體系統裡剝離出來。我沒有這方面的經驗，但可以想象，這將是一個非常長期和痛苦的過程。
下篇文章分享一下微服務架構的簡單模式。
(點擊放大圖像)
蘇槐，微信號Sulaohuai，青柳雲研發總監，現服務於神州數碼青柳雲團隊，曾就職於Oracle，新加坡電信等企業。擅長容器技術、微服務架構、敏捷開發及技術管理。
您需要 註冊一個InfoQ賬號 或者
登錄 才能進行評論。在您完成註冊後還需要進行一些設置。
獲得來自InfoQ的更多體驗。
現在正在從單體架構遷移到微服務架構，不過遇到困擾。現在系統根據項目大小不同，需要的服務器不同，最低隻要1臺，最高需要70多臺。采用微服務時，小項目成本控制不能保證。
子系統越多，比較小項目時候標準服務器運行多個docker，每個docker在進行累計服務器資源消耗比單體系統消耗要多。請教在單個服務器部署多個docker時整體服務器資源消耗等同於單體系統服務器資源消耗？
服務註冊發現已經在《如何快速搭建一個微服務架構》中講到瞭，可以在Infoq公眾號上看。
分佈式事務會講到可靠消息服務，TCC和最大可能通知三種方案，大概下個月初會發，可以關註Infoq或聊聊架構公眾號。
這個其實和微服務架構不在一個維度上，我們是通過使用容器平臺來解決的，能提高10倍的硬件利用率。
可以從三個角度來看這個問題：（一）如果單說微服務架構和單體應用的資源消耗，那麼微服務架構占用的資源要多，因為它需要啟動更多的Web服務器。（二）當系統出現性能問題，需要做橫向擴展時，微服務架構可以隻擴展某些微服務模塊，而單體應用需要擴展整個應用系統。（三）原來的單體應用放到標準服務器（例如4核8G的虛擬機）上時，為瞭避免應用間相互影響，空餘的內存和CPU是不能給其它應用來用的，使用Docker後，就可以將”標準服務器“上的資源完全利用起來。建議：將微服務架構的利弊和Docker的利弊分成兩個事情來看，會更清楚一些。
我們發現您在使用ad blocker。
我們理解您使用ad blocker的初衷，但為瞭保證InfoQ能夠繼續以免費方式為您服務，我們需要您的支持。InfoQ絕不會在未經您許可的情況下將您的數據提供給第三方。我們僅將其用於向讀者發送相關廣告內容。請您將InfoQ添加至白名單，感謝您的理解與支持。
AUGI SPORTS｜重機車靴｜重機車靴推薦｜重機專用車靴｜重機防摔鞋｜重機防摔鞋推薦｜重機防摔鞋
AUGI SPORTS｜augisports｜racing boots｜urban boots｜motorcycle boots
文章標籤
全站熱搜
留言列表
