【話題討論】理解微服務架構，實踐云原生應用！

gaokeke123

話題背景：

      微服務架構是一項在云中部署應用和服務的新技術。大部分圍繞微服務的爭論都集中在容器或其他技術是否能很好的實施微服務，而紅帽說API應該是重點。

微服務可以在“自己的程序”中運行，并通過“輕量級設備與HTTP型API進行溝通”。關鍵在于該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構（在現(xiàn)有系統(tǒng)中分布一個API）區(qū)分開來。在服務公開中，許多服務都可以被內(nèi)部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那么就必須縮小進程范圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程的架構。

討論內(nèi)容：

1.微服務的定義？微服務需要“微”到什么程度？

2.微服務的重大優(yōu)勢是什么？它是未來嗎？

3.微服務在實踐過程中最大的難點是什么？

4.微服務、容器技術兩者的關系？兩者結合帶來什么新趨勢？

5.怎么處理微服務與外部相連，以及獲取數(shù)據(jù)？

6.微服務與容器結合會發(fā)展出新趨勢--Cloud Native，什么是Cloud Native？（可選答）

活動時間：2019年7月30日-2019年8月18日

獎項設置：

    一等獎1名：2019中國系統(tǒng)架構師大會 門票1張

    二等獎3名：中國系統(tǒng)架構師大會（SACC）十周年紀念T恤一件

    三等獎若干：50個 IT168文庫金幣

備注：CU論壇與ITpub話題討論答案同步篩選，希望大家積極參與哦。

      2019年10月31日~11月2日，由 IT168 旗下 ITPUB 企業(yè)社區(qū)平臺主辦的第十一屆中國系統(tǒng)架構師大會（SACC2019)將在北京隆重召開。自2009年舉辦以來，大會云集了國內(nèi) CTO、研發(fā)總監(jiān)、高級系統(tǒng)架構師、開發(fā)工程師和IT經(jīng)理等技術人群，與會規(guī)模超千人。

      本屆大會繼續(xù)沿用四大主線并行的演講模式，設置業(yè)務系統(tǒng)架構設計、大數(shù)據(jù)平臺架構設計、數(shù)字化轉型實踐和開源架構設計四大主線，共1個主會場，20個技術專場，100+來自互聯(lián)網(wǎng)、金融、制造業(yè)、電商等領域嘉賓，將為廣大參會者提供一場最具價值的技術交流盛會。

      SACC2019 中國系統(tǒng)架構師大會，期待您的報名參與！報名鏈接：http://sacc.it168.com/

gaokeke123

歡迎大家踴躍參與話題討論哦~前排占樓

tomorrowcome

1.微服務的定義？微服務需要“微”到什么程度？

（1）每一個微服務是一個獨立的自治系統(tǒng)，不依賴外部組件，能夠獨立運行；

（2）對外只能通過API提供服務或者獲取服務；

（3）粒度足夠小。

微服務的粒度與團隊組織方式是相關，與業(yè)務功能的構成相關，與數(shù)據(jù)相關。

在業(yè)務功能方面，盡量做到一個模塊中的業(yè)務高度類聚集，和外部模塊做到松耦合，獲取靈活性；在數(shù)據(jù)方面，一個微服務盡量不要和外部頻繁的交互數(shù)據(jù)，大量的API交互對性能和可靠性都有影響。

2.微服務的重大優(yōu)勢是什么？它是未來嗎？

      微服務，是一種去中心化的架構。一般和更細粒度的容器配合使用，天生自帶很強的共生性。

從早期的集中式架構，到分布式架構，再到現(xiàn)在更細粒度化的微服務，其實一直朝著去中心化的趨勢發(fā)展，具備更強的靈活性以及更適合云的特點。

微服務是未來一種非常主要的、應用廣泛的架構，但并不一定說它會統(tǒng)治一切。微服務化更適合無狀態(tài)、高迭代的業(yè)務場景。

3.微服務在實踐過程中最大的難點是什么？

     微服務在實踐過程中，最大的問題是團隊之間的運作和管理�？低�定律提到，有什么樣的團隊組織方式，就有什么樣的業(yè)務架構。業(yè)務架構，是和團隊組織架構相匹配的，當我們把一個大的系統(tǒng)，拆分成小的服務時，團隊會隨之變化。團隊成員需要適應微服務的開發(fā)模式，微服務對每個程序員有著更高的要求。

微服務實踐的難點不在于沒法拆分，難點在于很多人的思想停留在以前的架構思想下。建議逐步改造、持續(xù)迭代地改造架構。新業(yè)務、新團隊可以獨立地采用微服務化運作。

4.微服務、容器技術兩者的關系？兩者結合帶來什么新趨勢？

      微服務是一種架構思想，而容器，或者說以Docker為代表的容器技術，是一種運行載體。容器天生適合細粒度的微服務，容器管理和分發(fā)需要Docker的支持。兩者結合，就是去中心化思想的實踐。

伴隨互聯(lián)網(wǎng)與云計算的發(fā)展，什么樣的架構或者產(chǎn)品研發(fā)模式是適合云模式的？是傳統(tǒng)的集中式架構嗎？分布式架構嗎？現(xiàn)在創(chuàng)業(yè)型公司的特點：完全基于云端，輕資產(chǎn)，小團隊作戰(zhàn)，快速的產(chǎn)品迭代。為了適應這些特點，必須基于云的原生特點去設計應用架構，所以微服務和容器發(fā)展的新趨勢，就是去實踐Cloud Native。

5.怎么處理微服務與外部相連，以及獲取數(shù)據(jù)？


      微服務是通過API對外提供服務，本身是一個獨立的自治系統(tǒng)，所以不存在需要與很多數(shù)據(jù)中心相互連接的情況；如果需要通訊，直接適用公網(wǎng)連接就可以。
換句話說，微服務和微服務之間的數(shù)據(jù)通訊是通過API調(diào)用的。沒有所謂的內(nèi)部的進程間、共享信號、共享內(nèi)存隊列的模式。一個微服務對外提供的服務一定是封裝好的、接口式的。

6.微服務與容器結合會發(fā)展出新趨勢--Cloud Native，什么是Cloud Native？

     在云時代，全部應用都基于云去構建，并不適合套用傳統(tǒng)的研發(fā)模式。Cloud Native是指云原生的應用架構，是專門針對云的架構。它主要包括三個部分，一種全新的架構思想（微服務），一種業(yè)務運行管理模式，以及一種團隊組織管理方式。關乎DevOps、小團隊、敏捷開發(fā)。Cloud Native既不是一個新的技術，也不是一套新的架構，而是產(chǎn)品研發(fā)、運營的全新模式。它是在云的生態(tài)場景生長出來的，和云的關系是一種魚和水的關系。

post200

微服務的定義？微服務需要“微”到什么程度？
就是將單一程序開發(fā)成一個微服務，每個微服務運行在自己的進程中，
并使用輕 量級機制通信，通常是 HTTP RESTFUL API。這些服務圍繞業(yè)務能力來劃分構建的，并通過
完全自動化部署機制來 獨立部署。 這些服務可以使用不同的編程語言，以及不同數(shù)據(jù)存儲技術，以保
證最低限度的集中式管理。
微服務的重大優(yōu)勢是什么？它是未來嗎？
優(yōu)點提升開發(fā)交流，每個服務足夠內(nèi)聚，足夠小，代碼容易理解；服務獨立測試、部署、升級、發(fā)布；按需定制的DFX，資源利用率，每個服務可以各自進行x擴展和z擴展，而且，每個服務可以根據(jù)自己的需要部署到合適的硬件服務器上；每個服務按需要選擇HA的模式，選擇接受服務的實例個數(shù)；容易擴大開發(fā)團隊，可以針對每個服務（service）組件開發(fā)團隊；提高容錯性（fault isolation），一個服務的內(nèi)存泄露并不會讓整個系統(tǒng)癱瘓；新技術的應用，系統(tǒng)不會被長期限制在某個技術棧上

mysdirma

微服務在實踐過程中最大的難點是什么？
微服務在實踐過程中，最大的問題是團隊之間的運作和管理的問題.因為微服務，對每個程序員的要求是比較高的：每個程序員的權責會更明顯，需要標準化接口、書寫規(guī)范文檔，而且一般需要有DevOps的工作。

mysdirma

怎么處理微服務與外部相連，以及獲取數(shù)據(jù)？
在設計時就需要考慮到微服務有哪些數(shù)據(jù)需求（見問題一的第二小問）：微服務都是通過API對外提供服務，本身是一個獨立的自治系統(tǒng)，所以不存在需要與很多數(shù)據(jù)中心相互連接的情況；如果需要通訊，直接適用公網(wǎng)連接就可以了。

lcc

微服務是一種架構風格，一個大型復雜軟件應用由一個或多個微服務組成。系統(tǒng)中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。在所有情況下，每個任務代表著一個小的業(yè)務能力�？梢栽凇白约旱某绦颉敝羞\行，并通過“輕量級設備與HTTP型API進行溝通”。關鍵在于該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構（在現(xiàn)有系統(tǒng)中分布一個API）區(qū)分開來。在服務公開中，許多服務都可以被內(nèi)部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那么就必須縮小進程范圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程

regatta

微服務的重大優(yōu)勢是什么？它是未來嗎？
每個服務都比較簡單，只關注于一個業(yè)務功能。
微服務架構方式是松耦合的，可以提供更高的靈活性。
微服務可通過最佳及最合適的不同的編程語言與工具進行開發(fā)，能夠做到有的放矢地解決針對性問題。
每個微服務可由不同團隊獨立開發(fā)，互不影響，加快推出市場的速度。
微服務架構是持續(xù)交付(CD)的巨大推動力，允許在頻繁發(fā)布不同服務的同時保持系統(tǒng)其他部分的可用性和穩(wěn)定性。

suliver

微服務架構的缺點有啥呀？

chunian

suliver 發(fā)表于 2019-08-02 16:35
微服務架構的缺點有啥呀？

運維開銷及成本增加：整體應用可能只需部署至一小片應用服務區(qū)集群，而微服務架構可能變成需要構建/測試/部署/運行數(shù)十個獨立的服務，并可能需要支持多種語言和環(huán)境。這導致一個整體式系統(tǒng)如果由20個微服務組成，可能需要40~60個進程。

必須有堅實的DevOps開發(fā)運維一體化技能：開發(fā)人員需要熟知運維與投產(chǎn)環(huán)境，開發(fā)人員也需要掌握必要的數(shù)據(jù)存儲技術如NoSQL，具有較強DevOps技能的人員比較稀缺，會帶來招聘人才方面的挑戰(zhàn)。

隱式接口及接口匹配問題：把系統(tǒng)分為多個協(xié)作組件后會產(chǎn)生新的接口，這意味著簡單的交叉變化可能需要改變許多組件，并需協(xié)調(diào)一起發(fā)布。在實際環(huán)境中，一個新品發(fā)布可能被迫同時發(fā)布大量服務，由于集成點的大量增加，微服務架構會有更高的發(fā)布風險。

代碼重復：某些底層功能需要被多個服務所用，為了避免將“同步耦合引入到系統(tǒng)中”，有時需要向不同服務添加一些代碼，這就會導致代碼重復。

分布式系統(tǒng)的復雜性：作為一種分布式系統(tǒng)，微服務引入了復雜性和其他若干問題，例如網(wǎng)絡延遲、容錯性、消息序列化、不可靠的網(wǎng)絡、異步機制、版本化、差異化的工作負載等，開發(fā)人員需要考慮以上的分布式系統(tǒng)問題。

異步機制：微服務往往使用異步編程、消息與并行機制，如果應用存在跨微服務的事務性處理，其實現(xiàn)機制會變得復雜化。

可測性的挑戰(zhàn)：在動態(tài)環(huán)境下服務間的交互會產(chǎn)生非常微妙的行為，難以可視化及全面測試。經(jīng)典微服務往往不太重視測試，更多的是通過監(jiān)控發(fā)現(xiàn)生產(chǎn)環(huán)境的異常，進而快速回滾或采取其他必要的行動。但對于特別在意風險規(guī)避監(jiān)管或投產(chǎn)環(huán)境錯誤會產(chǎn)生顯著影響的場景下需要特別注意。


希望對你有所幫助