cloud native （國內譯為「雲原生」），最早是 matt stine 提出的乙個概念。與微服務一樣，cloud native 並不是一種具體的技術，而是一類思想的集合，包括devops、持續交付（continuous delivery）、微服務（microservices）、敏捷基礎設施（agile infrastructure）、康威定律（conways law）等，以及根據商業能力對公司進行重組。cloud native 既包含技術（微服務，敏捷基礎設施），也包含管理（devops，持續交付，康威定律，重組等）。所以，cloud native 也可以說是一系列cloud技術、企業管理方法的集合。
cloud native 具備有以下特性：
以雲為基礎架構
雲服務無服務
可擴充套件高可用
敏捷雲優先
等等
微服務雖然帶來了架構上的優勢，但同時也引入了複雜性。我們不得使用一些元件，來解決技術複雜性提高之後帶來的問題：
服務註冊中心：乙個服務可以有多個例項，那麼我們在向乙個服務發出請求的時候，怎麼知道這個服務有哪些例項呢？為了減少手工維護的麻煩，我們需要服務註冊中心。每個服務例項在啟動時，向註冊中心註冊自己的ip位址等資訊。這樣，服務在呼叫別的服務的介面時，就可以通過註冊中心，查詢到其他服務的例項，向例項發起請求。沃爾茲總店就是起到註冊中心的作用。
負載均衡：由於乙個服務可以有多個例項，所以不管是來自外部客戶端的請求，還是微服務系統內部服務之間發起的請求，都需要引入負載均衡的機制，來發揮多例項集群的作用。有的書也稱這兩種負載均衡為伺服器端負載均衡和客戶端負載均衡，各自具有代表性意義的實現分別是nginx和ribbon。
api gateway：乙個外部請求過來之後，我們需要知道這個請求是發給哪個服務的，也就是我們需要乙個請求路由的功能，比如/cm/*的請求，要發給客戶管理服務，/om/*的請求，要發給訂單管理服務。另外，不是所有請求都可以被我們系統處理的，我們需要判斷這個請求是否攜帶一些必要的鑑權資訊，並對其進行鑑權，也就是請求過濾的功能。而api gateway，就是起到了這兩個功能，它就像整個微服務系統的門面，所有請求，都要先經過它的處理，才會**到對應的服務。
微服務系統的衍生元件還有很多，比如對各個服務進行的配置管理的分布式配置中心、各個服務之間進行訊息通訊的訊息匯流排和訊息驅動機制（上圖中的message queue）等。
「微服務」 是業內最近兩三年業內很火的 buzzword，遷移到微服務架構，大多強調這些好處：
松耦合獨立發布
快速迭代
故障隔離
增加重用
經過服務的拆分，將複雜到難以移動的單體應用，拆分為多個可以獨立部署的服務，單個服務的複雜性遠遠小於整體，這樣不同服務的開發者可以並行開發，從而提高開發效率；因為服務的細粒度，可以 assign 給乙個具體的人讓他負責，隨著業務的增長對服務做定向擴容；同時因為服務的隔離性，可以隔離故障，提高整體的穩定性。
rpc （遠端過程呼叫）是服務化體系中基礎的基礎，但是慢慢的我們發現 rpc 並非分拆的唯一選擇。基於 rpc 的水平分拆會引入中間層次，增加聯調的環節，對於快速開發的新業務而言，無法忽視額外的聯調成本。
這裡我們得到的啟發是，服務的分拆並非 rpc 不可。相反，我們希望看到更少的 rpc，更多的內聚。更少的 rpc 介面意味著更小的服務邊界，更穩定的介面，更少的 break change。內聚意味著允許功能需求的獨立演進，對其他業務的影響降到最低，也意味著內聚的業務模組內部，可以充分利用快取來優化效能。
理想的世界裡，服務邊界恰好匹配於業務邊界。然而工程師首先要承擔業務需求的壓力，只能抽時間重構拆分，業務邊界也並不總是如新專案那樣明晰。
這意味著要考慮優先順序，也需要在拆分之前認真地思考業務的邊界。排定優先順序，考量拆分的收益與風險即可。劃分業務的邊界，則需要更多的思考拆分後的未來將如何溝通協作，然後再考慮技術因素。目前我們主要有這幾個考量：
是否擁有獨立團隊來維護，或者是否擁有發展為一項獨立業務的潛力；
圍繞領域而非 feature，有明確的維護團隊，避免過於細粒度；
拆分之後，能否改善現有的合作流程；
能否幫助區分核心、非核心業務，改善穩定性；
以 feed 為例，它首先擁有獨立團隊維護，通過拆分，技術層面上允許 feed 團隊重構掉下層服務與上層展現之間的冗餘 rpc 呼叫，且呼叫模式較 uniform，在產品層面接受資料最終一致性的前提下可以通過 ttl 快取提公升效能，乃至按自己的業務場景做更細緻的優化（優化結束後我們的某些介面 p95 效能加快了一倍）；更重要的是對協作方式的影響，未來專欄、問答等生產資訊的垂直業務，只提供乙個 rpc 介面對接 feed 流即可，而不必整合到主站，這一來 「接入 feed」 流程的參與者，從 feed 組、垂直業務、主站三方，簡化為 feed 組和垂直業務雙方；此外 feed 通過 ttl 快取，實質上冗餘了乙份垂直業務的資料，配合斷路器的使用，依賴的垂直業務的抖動甚至崩潰在 feed 這邊都可以優雅降級且保持正常展現了。將 feed 與主站的變更相隔離，也有助於改進作為一項核心業務的 feed 的穩定性。
在垂直業務之外，也存在多數業務都會重用的公共服務，如使用者、話題、網頁抓取、多**、推送等。業務服務和公共服務在關注點上有所不同：
我們希望業務服務快速迭代，更快、更好地響應多變的業務需求，更多地面向前端工程師；
我們希望公共服務穩定可靠，較少發生改動，但 sla 要好，更多地為業務重用；
這裡會形成乙個自然的分層：上層業務求快、下層公共服務求穩。
如何實現前端微服務化？
譯者按 微服務在後端開發中大行其道，其實對於越來越複雜的前端應用來說，微服務也是一種不錯的選擇。譯者 fundebug 對於網頁應用，現代的開發方法使得前端部分變得越來越大，與之對應的後端反而變小。我們的 weld的 中90 都是前端相關。我可以想象大多數現代的網頁應用都類似。網頁應用一直在演化，網...
如何實現前端微服務化？
譯者按 微服務在後端開發中大行其道，其實對於越來越複雜的前端應用來說，微服務也是一種不錯的選擇。譯者 fundebug 對於網頁應用，現代的開發方法使得前端部分變得越來越大，與之對應的後端反而變小。我們的 weld的 中90 都是前端相關。我可以想象大多數現代的網頁應用都類似。網頁應用一直在演化，網...
如何實現前端微服務化
譯者按 微服務在後端開發中大行其道，其實對於越來越複雜的前端應用來說，微服務也是一種不錯的選擇。譯者 fundebug 對於網頁應用，現代的開發方法使得前端部分變得越來越大，與之對應的後端反而變小。我們的 weld的 中90 都是前端相關。我可以想象大多數現代的網頁應用都類似。網頁應用一直在演化，網...