亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: 【話題討論】理解微服務(wù)架構(gòu)，實踐云原生應(yīng)用！ [打印本頁]
作者: gaokeke123    時間: 2019-07-30 14:17
標(biāo)題: 【話題討論】理解微服務(wù)架構(gòu)，實踐云原生應(yīng)用！


話題背景：

      微服務(wù)架構(gòu)是一項在云中部署應(yīng)用和服務(wù)的新技術(shù)。大部分圍繞微服務(wù)的爭論都集中在容器或其他技術(shù)是否能很好的實施微服務(wù)，而紅帽說API應(yīng)該是重點。
微服務(wù)可以在“自己的程序”中運行，并通過“輕量級設(shè)備與HTTP型API進(jìn)行溝通”。關(guān)鍵在于該服務(wù)可以在自己的程序中運行。通過這一點我們就可以將服務(wù)公開與微服務(wù)架構(gòu)（在現(xiàn)有系統(tǒng)中分布一個API）區(qū)分開來。在服務(wù)公開中，許多服務(wù)都可以被內(nèi)部獨立進(jìn)程所限制。如果其中任何一個服務(wù)需要增加某種功能，那么就必須縮小進(jìn)程范圍。在微服務(wù)架構(gòu)中，只需要在特定的某種服務(wù)中增加所需功能，而不影響整體進(jìn)程的架構(gòu)。

討論內(nèi)容：

1.微服務(wù)的定義？微服務(wù)需要“微”到什么程度？
2.微服務(wù)的重大優(yōu)勢是什么？它是未來嗎？
3.微服務(wù)在實踐過程中最大的難點是什么？
4.微服務(wù)、容器技術(shù)兩者的關(guān)系？兩者結(jié)合帶來什么新趨勢？
5.怎么處理微服務(wù)與外部相連，以及獲取數(shù)據(jù)？
6.微服務(wù)與容器結(jié)合會發(fā)展出新趨勢--Cloud Native，什么是Cloud Native？（可選答）

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

獎項設(shè)置：

    一等獎1名：2019中國系統(tǒng)架構(gòu)師大會 門票1張
    二等獎3名：中國系統(tǒng)架構(gòu)師大會（SACC）十周年紀(jì)念T恤一件
    三等獎若干：50個 IT168文庫金幣

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

      2019年10月31日~11月2日，由 IT168 旗下 ITPUB 企業(yè)社區(qū)平臺主辦的第十一屆中國系統(tǒng)架構(gòu)師大會（SACC2019)將在北京隆重召開。自2009年舉辦以來，大會云集了國內(nèi) CTO、研發(fā)總監(jiān)、高級系統(tǒng)架構(gòu)師、開發(fā)工程師和IT經(jīng)理等技術(shù)人群，與會規(guī)模超千人。
      本屆大會繼續(xù)沿用四大主線并行的演講模式，設(shè)置業(yè)務(wù)系統(tǒng)架構(gòu)設(shè)計、大數(shù)據(jù)平臺架構(gòu)設(shè)計、數(shù)字化轉(zhuǎn)型實踐和開源架構(gòu)設(shè)計四大主線，共1個主會場，20個技術(shù)專場，100+來自互聯(lián)網(wǎng)、金融、制造業(yè)、電商等領(lǐng)域嘉賓，將為廣大參會者提供一場最具價值的技術(shù)交流盛會。

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

作者: gaokeke123    時間: 2019-07-31 13:40
歡迎大家踴躍參與話題討論哦~前排占樓
作者: tomorrowcome    時間: 2019-07-31 13:51
1.微服務(wù)的定義？微服務(wù)需要“微”到什么程度？

（1）每一個微服務(wù)是一個獨立的自治系統(tǒng)，不依賴外部組件，能夠獨立運行；
（2）對外只能通過API提供服務(wù)或者獲取服務(wù)；
（3）粒度足夠小。
微服務(wù)的粒度與團(tuán)隊組織方式是相關(guān)，與業(yè)務(wù)功能的構(gòu)成相關(guān)，與數(shù)據(jù)相關(guān)。
在業(yè)務(wù)功能方面，盡量做到一個模塊中的業(yè)務(wù)高度類聚集，和外部模塊做到松耦合，獲取靈活性；在數(shù)據(jù)方面，一個微服務(wù)盡量不要和外部頻繁的交互數(shù)據(jù)，大量的API交互對性能和可靠性都有影響。

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

      微服務(wù)，是一種去中心化的架構(gòu)。一般和更細(xì)粒度的容器配合使用，天生自帶很強的共生性。
從早期的集中式架構(gòu)，到分布式架構(gòu)，再到現(xiàn)在更細(xì)粒度化的微服務(wù)，其實一直朝著去中心化的趨勢發(fā)展，具備更強的靈活性以及更適合云的特點。
微服務(wù)是未來一種非常主要的、應(yīng)用廣泛的架構(gòu)，但并不一定說它會統(tǒng)治一切。微服務(wù)化更適合無狀態(tài)、高迭代的業(yè)務(wù)場景。

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

     微服務(wù)在實踐過程中，最大的問題是團(tuán)隊之間的運作和管理�？低商岬�，有什么樣的團(tuán)隊組織方式，就有什么樣的業(yè)務(wù)架構(gòu)。業(yè)務(wù)架構(gòu)，是和團(tuán)隊組織架構(gòu)相匹配的，當(dāng)我們把一個大的系統(tǒng)，拆分成小的服務(wù)時，團(tuán)隊會隨之變化。團(tuán)隊成員需要適應(yīng)微服務(wù)的開發(fā)模式，微服務(wù)對每個程序員有著更高的要求。
微服務(wù)實踐的難點不在于沒法拆分，難點在于很多人的思想停留在以前的架構(gòu)思想下。建議逐步改造、持續(xù)迭代地改造架構(gòu)。新業(yè)務(wù)、新團(tuán)隊可以獨立地采用微服務(wù)化運作。

4.微服務(wù)、容器技術(shù)兩者的關(guān)系？兩者結(jié)合帶來什么新趨勢？

      微服務(wù)是一種架構(gòu)思想，而容器，或者說以Docker為代表的容器技術(shù)，是一種運行載體。容器天生適合細(xì)粒度的微服務(wù)，容器管理和分發(fā)需要Docker的支持。兩者結(jié)合，就是去中心化思想的實踐。
伴隨互聯(lián)網(wǎng)與云計算的發(fā)展，什么樣的架構(gòu)或者產(chǎn)品研發(fā)模式是適合云模式的？是傳統(tǒng)的集中式架構(gòu)嗎？分布式架構(gòu)嗎？現(xiàn)在創(chuàng)業(yè)型公司的特點：完全基于云端，輕資產(chǎn)，小團(tuán)隊作戰(zhàn)，快速的產(chǎn)品迭代。為了適應(yīng)這些特點，必須基于云的原生特點去設(shè)計應(yīng)用架構(gòu)，所以微服務(wù)和容器發(fā)展的新趨勢，就是去實踐Cloud Native。

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


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

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

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




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


作者: mysdirma    時間: 2019-08-01 14:58
微服務(wù)在實踐過程中最大的難點是什么？
微服務(wù)在實踐過程中，最大的問題是團(tuán)隊之間的運作和管理的問題.因為微服務(wù)，對每個程序員的要求是比較高的：每個程序員的權(quán)責(zé)會更明顯，需要標(biāo)準(zhǔn)化接口、書寫規(guī)范文檔，而且一般需要有DevOps的工作。
作者: mysdirma    時間: 2019-08-02 10:52
怎么處理微服務(wù)與外部相連，以及獲取數(shù)據(jù)？
在設(shè)計時就需要考慮到微服務(wù)有哪些數(shù)據(jù)需求（見問題一的第二小問）：微服務(wù)都是通過API對外提供服務(wù)，本身是一個獨立的自治系統(tǒng)，所以不存在需要與很多數(shù)據(jù)中心相互連接的情況；如果需要通訊，直接適用公網(wǎng)連接就可以了。
作者: lcc    時間: 2019-08-02 14:04
微服務(wù)是一種架構(gòu)風(fēng)格，一個大型復(fù)雜軟件應(yīng)用由一個或多個微服務(wù)組成。系統(tǒng)中的各個微服務(wù)可被獨立部署，各個微服務(wù)之間是松耦合的。每個微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下，每個任務(wù)代表著一個小的業(yè)務(wù)能力�？梢栽凇白约旱某绦颉敝羞\行，并通過“輕量級設(shè)備與HTTP型API進(jìn)行溝通”。關(guān)鍵在于該服務(wù)可以在自己的程序中運行。通過這一點我們就可以將服務(wù)公開與微服務(wù)架構(gòu)（在現(xiàn)有系統(tǒng)中分布一個API）區(qū)分開來。在服務(wù)公開中，許多服務(wù)都可以被內(nèi)部獨立進(jìn)程所限制。如果其中任何一個服務(wù)需要增加某種功能，那么就必須縮小進(jìn)程范圍。在微服務(wù)架構(gòu)中，只需要在特定的某種服務(wù)中增加所需功能，而不影響整體進(jìn)程

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

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

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

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

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

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

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

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


希望對你有所幫助
作者: post200    時間: 2019-08-02 16:59
微服務(wù)與容器結(jié)合會發(fā)展出新趨勢--Cloud Native，什么是Cloud Native？
CloudNative 最大的思維轉(zhuǎn)變當(dāng)屬 Stateless Infrastructure（無狀態(tài)基礎(chǔ)設(shè)施）。這樣可以大幅度保障應(yīng)用的可用性和水平擴展能力，當(dāng)傳統(tǒng)的計算資源和存儲資源已經(jīng)通過云計算技術(shù)達(dá)到了海量。應(yīng)用的瓶頸就來自于應(yīng)用架構(gòu)和基礎(chǔ)設(shè)施結(jié)構(gòu)。如果還在思考基礎(chǔ)設(shè)施的狀態(tài)如何監(jiān)控和保存，就又進(jìn)入了老的思維模式，只不過換了新的工具而已。
作者: aloki    時間: 2019-08-04 00:01
1.微服務(wù)的定義？微服務(wù)需要“微”到什么程度？
微服務(wù) (Microservices) 是一種軟件架構(gòu)風(fēng)格，它是以專注于單一責(zé)任與功能的小型功能區(qū)塊 (Small Building Blocks) 為基礎(chǔ)，利用模塊化的方式組合出復(fù)雜的大型應(yīng)用程序，各功能區(qū)塊使用與語言無關(guān) (Language-Independent/Language agnostic) 的 API 集相互通信。
盡管“微服務(wù)”早已成為一種極具人氣的架構(gòu)類型，但這一名稱卻并不能準(zhǔn)確反映服務(wù)的實際規(guī)�！獡Q言之，“微”服務(wù)并不一定微，具體規(guī)�？芍^多種多樣。規(guī)模較小的團(tuán)隊則由六人組成，負(fù)責(zé)支持六項服務(wù)。

2.微服務(wù)的重大優(yōu)勢是什么？它是未來嗎？
·提升開發(fā)交流，每個服務(wù)足夠內(nèi)聚，足夠小，代碼容易理解；
·服務(wù)獨立測試、部署、升級、發(fā)布；
·按需定制的DFX，資源利用率，每個服務(wù)可以各自進(jìn)行x擴展和z擴展，而且，每個服務(wù)可以根據(jù)自己的需要部署到合適的硬件服務(wù)器上；
·每個服務(wù)按需要選擇HA的模式，選擇接受服務(wù)的實例個數(shù)；
·容易擴大開發(fā)團(tuán)隊，可以針對每個服務(wù)（service）組件開發(fā)團(tuán)隊；
·提高容錯性（fault isolation），一個服務(wù)的內(nèi)存泄露并不會讓整個系統(tǒng)癱瘓；
·新技術(shù)的應(yīng)用，系統(tǒng)不會被長期限制在某個技術(shù)棧上；

微服務(wù)架構(gòu)有很多吸引人的地方，但在擁抱微服務(wù)之前，也需要認(rèn)清它所帶來的挑戰(zhàn)。

3.微服務(wù)在實踐過程中最大的難點是什么？
·開發(fā)人員要處理分布式系統(tǒng)的復(fù)雜性；
·服務(wù)之間的分布式通信問題；
·服務(wù)的注冊與發(fā)現(xiàn)問題；
·服務(wù)之間的分布式事務(wù)問題；
·數(shù)據(jù)隔離再來的報表處理問題；
·服務(wù)之間的分布式一致性問題；
·服務(wù)管理的復(fù)雜性，服務(wù)的編排；
·不同服務(wù)實例的管理。

4.微服務(wù)、容器技術(shù)兩者的關(guān)系？兩者結(jié)合帶來什么新趨勢？
雖然使用一般的服務(wù)器虛擬化技術(shù)就能應(yīng)用于微服務(wù)的管理，但容器技術(shù) (Container Technology) 如 Docker 會更加地適合發(fā)展微服務(wù)的運算資源管理技術(shù)。Docker
作為一種開源的應(yīng)用容器引擎，幫助開發(fā)者將他們的應(yīng)用以及依賴打包到一個可移植的容器中，便于應(yīng)用的部署和擴展。而隨之產(chǎn)生的微容器概念和微服務(wù)正好相輔相成，通過Docker 封裝的應(yīng)用可以輕松運行在以擴容能力見長的云計算平臺上。數(shù)人云作為專業(yè)的數(shù)據(jù)中心管理系統(tǒng)，提供了基于 Mesos 和Docker 技術(shù)的企業(yè)級容器云生產(chǎn)環(huán)境，通過一鍵部署、橫向擴展、持續(xù)集成等特性，助力微服務(wù)架構(gòu)在企業(yè)應(yīng)用環(huán)境的實踐。

5.怎么處理微服務(wù)與外部相連，以及獲取數(shù)據(jù)？
單個微服務(wù)在上線的時候，會向服務(wù)探索中心（如：Consul）注冊自己的 IP 位置、服務(wù)內(nèi)容，如此一來就不需要向每個微服務(wù)表明自己的 IP 位置，也就不用替每個微服務(wù)單獨設(shè)置。當(dāng)服務(wù)需要調(diào)用另一個服務(wù)的時候，會去詢問服務(wù)探索中心該服務(wù)的 IP 位置為何，得到位置后即可直接向目標(biāo)服務(wù)調(diào)用。

這么做的用意是可以統(tǒng)一集中所有服務(wù)的位置，就不會分散于每個微服務(wù)中，且服務(wù)探索中心可以每隔一段時間就向微服務(wù)進(jìn)行健康檢查（如透過：TCP 調(diào)用、HTTP 調(diào)用、Ping），倘若該服務(wù)在時間內(nèi)沒有回應(yīng)，則將其從服務(wù)中心移除，避免其他微服務(wù)對一個無回應(yīng)的服務(wù)進(jìn)行調(diào)用。

作者: laputa73    時間: 2019-08-05 13:39
本帖最后由 laputa73 于 2019-08-05 13:43 編輯

這個話題比較熱門，
1.微服務(wù)的定義？微服務(wù)需要“微”到什么程度？
這個問題其實是微服務(wù)最核心的問題。
微服務(wù)其實并沒有明確的定義，相對于單體應(yīng)用，微服務(wù)有明顯的差異。
但是相對于分布式的多服務(wù)體系，微服務(wù)的差異體現(xiàn)在哪里？
傳統(tǒng)的SOA同樣有服務(wù)注冊、服務(wù)網(wǎng)關(guān)、服務(wù)路由。
微服務(wù)雖然可以脫離網(wǎng)關(guān)，只通過注冊中心尋址，p2p調(diào)用，但是最佳的推薦應(yīng)用方式仍然是通過網(wǎng)關(guān)。
所以，微服務(wù)更多是一個理念，而不是一個明確的概念。
微服務(wù)是不是越微越好？
答案我認(rèn)為是否定的。
一個上百個api的系統(tǒng)，通過上百個服務(wù)來實現(xiàn)，會給運維來來無窮無盡的煩惱。
相反，類似的功能，聚合到一個服務(wù)中集中實現(xiàn)，效率更高�？傮w分為10來個服務(wù)可能就足夠，
從單體到分布式集群是一個質(zhì)的變化，但是從分布式到微服務(wù)，只是一個量的調(diào)整。

2.微服務(wù)的重大優(yōu)勢是什么？它是未來嗎？
微服務(wù)最大的優(yōu)勢是統(tǒng)一了分布式RPC接口，讓進(jìn)程間通信和服務(wù)通信成為了統(tǒng)一模式，
只要分布式調(diào)用的需求存在，微服務(wù)的思想就在。
相對于傳統(tǒng)的單體系統(tǒng)，微服務(wù)主要的革命是去掉了session，強制api無狀態(tài).

3.微服務(wù)在實踐過程中最大的難點是什么？
粒度拆分的決策。
服務(wù)之間數(shù)據(jù)一致性問題。
運維問題。
多語言問題。
還有一個內(nèi)外劃分的問題，傳統(tǒng)的系統(tǒng)功能明確，內(nèi)部系統(tǒng)走rpc,外部系統(tǒng)通過soa相互通信�，F(xiàn)在都統(tǒng)一成微服務(wù)了。
誰是內(nèi)，誰是外？系統(tǒng)邊界在哪？服務(wù)中心需要建一套，還是多套？

4.微服務(wù)、容器技術(shù)兩者的關(guān)系？兩者結(jié)合帶來什么新趨勢？
沒有容器(docker)，也會有微服務(wù)。各種語言都有自己的web/rest app容器。
例如java的spring boot, python的flask.
但是有了docker容器，微服務(wù)的隔離更徹底，部署更清晰。
而且，依托k8s的容器調(diào)度，可以實現(xiàn)更高層次的微服務(wù)治理。

5.怎么處理微服務(wù)與外部相連，以及獲取數(shù)據(jù)？
微服務(wù)的數(shù)據(jù)同步是個很復(fù)雜的問題。
理論上微服務(wù)之間只存在api調(diào)用. 但是每個微服務(wù)自己搞一個數(shù)據(jù)庫是不現(xiàn)實的。
所以系統(tǒng)中需要有一部分服務(wù)，單獨處理數(shù)據(jù)。成為數(shù)據(jù)服務(wù)。
然后通過這些服務(wù)，暴露數(shù)據(jù)操作接口。
對于這些數(shù)據(jù)服務(wù)，可以直接操作數(shù)據(jù)庫，本質(zhì)上和傳統(tǒng)的服務(wù)/DAO這些沒有太大差別。

微服務(wù)區(qū)分內(nèi)外，和外部服務(wù)交互一定要過網(wǎng)關(guān)。
如果從外部獲取數(shù)據(jù)，量小的走api,量大的可能走專用通道，例如文件，隊列。

6.微服務(wù)與容器結(jié)合會發(fā)展出新趨勢--Cloud Native，什么是Cloud Native？（可選答）
云原生的概念是相對于直接把老系統(tǒng)遷移到容器、虛機部署而言的。
實際上，只要用上了docker+微服務(wù)這一套體系。支持了集群擴縮容，自然就是云原生了。

多說一句，目前的的微服務(wù)架構(gòu)，spring cloud還是主流
但是和云原生結(jié)合，service mesh(istio)才是更純粹的微服務(wù)架構(gòu)。



作者: oswald    時間: 2019-08-05 16:32
請問各位大佬，什么時候應(yīng)該使用微服務(wù)？
作者: nt1979    時間: 2019-08-05 17:22
哪些應(yīng)用可以從微服務(wù)收益？
作者: mysdirma    時間: 2019-08-05 17:43
回復(fù) 16# nt1979

作者: renxiao2003    時間: 2019-08-06 11:27
1.微服務(wù)的定義？微服務(wù)需要“微”到什么程度？
將單一應(yīng)用劃分為一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、配合，為用戶提供最終價值的架構(gòu)體系。而每個服務(wù)運行在獨立的進(jìn)程中，服務(wù)之間采用輕量級通信（通常是基于HTTP協(xié)議的Rest API），并且每個服務(wù)都承載著獨立的業(yè)務(wù)單元責(zé)任，能夠被獨立的部署和發(fā)布。
微服務(wù)不需要像普通服務(wù)那樣成為一種獨立的功能或者獨立的資源。定義中稱，微服務(wù)是需要與業(yè)務(wù)能力相匹配，這種說法完全正確。不幸的是，仍然意味著，如果能力模型粒度的設(shè)計是錯誤的，那么，我們就必須付出很多代價。如果你閱讀了Fowler的整篇文章，你會發(fā)現(xiàn)，其中的指導(dǎo)建議是非常實用的。在決定將所有組件組合到一起時，開發(fā)人員需要非常確信這些組件都會有所改變，并且規(guī)模也會發(fā)生變化。服務(wù)粒度越粗，就越難以符合規(guī)定原則。服務(wù)粒度越細(xì)，就越能夠靈活地降低變化和負(fù)載所帶來的影響。然而，利弊之間的權(quán)衡過程是非常復(fù)雜的，我們要在配置和資金模型的基礎(chǔ)上考慮到基礎(chǔ)設(shè)施的成本問題。
微服務(wù)到底應(yīng)該微到什么程度，根據(jù)個人觀點，不能太微，也不能不微。太微了容易造成資源的浪費，比如一個計算器功能，我們把加減乘除都做成微服務(wù)（即加是微服務(wù)，減也是）那么不管是使用者還是提供者都很繁瑣，而且容易造成資源浪費，畢竟就算是用容器，容器本身也是需要一個運行環(huán)境的；如果不微，把所有功能都糅合到一起，那么哪天更新一個功能可能就要停止所有的服務(wù)。造成所有服務(wù)中斷。
2.微服務(wù)的重大優(yōu)勢是什么？它是未來嗎？
優(yōu)勢：首先，通過分解巨大單體式應(yīng)用為多個服務(wù)方法解決了復(fù)雜性問題。第二，這種架構(gòu)使得每個服務(wù)都可以有專門開發(fā)團(tuán)隊來開發(fā)。第三，微服務(wù)架構(gòu)模式是每個微服務(wù)獨立的部署。最后，微服務(wù)架構(gòu)模式使得每個服務(wù)獨立擴展。
將一個復(fù)雜的業(yè)務(wù)分解成若干小的業(yè)務(wù)，每個業(yè)務(wù)拆分成一個服務(wù)，服務(wù)的邊界明確，將復(fù)雜的問題簡單化。由于微服務(wù)系統(tǒng)是分布式系統(tǒng) ，服務(wù)與服務(wù)之間沒有任何的禍合 。服務(wù)與服務(wù)之問通過 HTTP 網(wǎng)絡(luò)通信協(xié)議來通信，單個微服務(wù)內(nèi)部高度禍合，服務(wù)與服務(wù)之間完全獨立，無調(diào)合。如果是一個單體的應(yīng)用，由于業(yè)務(wù)的復(fù)雜性、代碼的禍合性，以及可能存在的歷史問題。微服務(wù)的每個服務(wù)單元都是獨立部署的 ，即獨立運行在某個進(jìn)程里。微服務(wù)的修改和部署對其他服務(wù)沒有影響。微服務(wù)在 CAP 理論中采用的是 AP 架構(gòu)，即 具有高可用和分區(qū)容錯 的特點 。
微服務(wù)（架構(gòu)）應(yīng)該是未來軟件（架構(gòu)）的趨勢。
3.微服務(wù)在實踐過程中最大的難點是什么？
『微服務(wù)』強調(diào)了服務(wù)大小，實際上，有一些開發(fā)者鼓吹建立稍微大一些的，10-100 LOC服務(wù)組。
微服務(wù)應(yīng)用是分布式系統(tǒng)，由此會帶來固有的復(fù)雜性。開發(fā)者需要在RPC或者消息傳遞之間選擇并完成進(jìn)程間通訊機制。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。當(dāng)然這并不是什么難事，但相對于單體式應(yīng)用中通過語言層級的方法或者進(jìn)程調(diào)用，微服務(wù)下這種技術(shù)顯得更復(fù)雜一些。
另外一個關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構(gòu)。商業(yè)交易中同時給多個業(yè)務(wù)分主體更新消息很普遍。這種交易對于單體式應(yīng)用來說很容易，因為只有一個數(shù)據(jù)庫。在微服務(wù)架構(gòu)應(yīng)用中，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫。使用分布式交易并不一定是好的選擇，不僅僅是因為CAP理論，還因為今天高擴展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發(fā)者提出了更高的要求和挑戰(zhàn)。

測試一個基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)。比如，采用流行的Spring Boot架構(gòu)，對一個單體式web應(yīng)用，測試它的REST API，是很容易的事情。反過來，同樣的服務(wù)測試需要啟動和它有關(guān)的所有服務(wù)（至少需要這些服務(wù)的stubs）。再重申一次，不能低估了采用微服務(wù)架構(gòu)帶來的復(fù)雜性。

另外一個挑戰(zhàn)在于，微服務(wù)架構(gòu)模式應(yīng)用的改變將會波及多個服務(wù)。比如，假設(shè)你在完成一個案例，需要修改服務(wù)A、B、C，而A依賴B，B依賴C。在單體式應(yīng)用中，你只需要改變相關(guān)模塊，整合變化，部署就好了。對比之下，微服務(wù)架構(gòu)模式就需要考慮相關(guān)改變對不同服務(wù)的影響。比如，你需要更新服務(wù)C，然后是B，最后才是A，幸運的是，許多改變一般只影響一個服務(wù)，而需要協(xié)調(diào)多服務(wù)的改變很少。

部署一個微服務(wù)應(yīng)用也很復(fù)雜，一個分布式應(yīng)用只需要簡單在復(fù)雜均衡器后面部署各自的服務(wù)器就好了。每個應(yīng)用實例是需要配置諸如數(shù)據(jù)庫和消息中間件等基礎(chǔ)服務(wù)。
4.微服務(wù)、容器技術(shù)兩者的關(guān)系？兩者結(jié)合帶來什么新趨勢？
另外一個關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫架構(gòu)。商業(yè)交易中同時給多個業(yè)務(wù)分主體更新消息很普遍。這種交易對于單體式應(yīng)用來說很容易，因為只有一個數(shù)據(jù)庫。在微服務(wù)架構(gòu)應(yīng)用中，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫。使用分布式交易并不一定是好的選擇，不僅僅是因為CAP理論，還因為今天高擴展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發(fā)者提出了更高的要求和挑戰(zhàn)。

測試一個基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)。比如，采用流行的Spring Boot架構(gòu)，對一個單體式web應(yīng)用，測試它的REST API，是很容易的事情。反過來，同樣的服務(wù)測試需要啟動和它有關(guān)的所有服務(wù)（至少需要這些服務(wù)的stubs）。再重申一次，不能低估了采用微服務(wù)架構(gòu)帶來的復(fù)雜性。

另外一個挑戰(zhàn)在于，微服務(wù)架構(gòu)模式應(yīng)用的改變將會波及多個服務(wù)。比如，假設(shè)你在完成一個案例，需要修改服務(wù)A、B、C，而A依賴B，B依賴C。在單體式應(yīng)用中，你只需要改變相關(guān)模塊，整合變化，部署就好了。對比之下，微服務(wù)架構(gòu)模式就需要考慮相關(guān)改變對不同服務(wù)的影響。比如，你需要更新服務(wù)C，然后是B，最后才是A，幸運的是，許多改變一般只影響一個服務(wù)，而需要協(xié)調(diào)多服務(wù)的改變很少。
部署一個微服務(wù)應(yīng)用也很復(fù)雜，一個分布式應(yīng)用只需要簡單在復(fù)雜均衡器后面部署各自的服務(wù)器就好了。每個應(yīng)用實例是需要配置諸如數(shù)據(jù)庫和消息中間件等基礎(chǔ)服務(wù)。
微服務(wù)與容器結(jié)合能夠更好的發(fā)揮和充分的利用計算機的資源。
5.怎么處理微服務(wù)與外部相連，以及獲取數(shù)據(jù)？
對外部有了依賴
微服務(wù)架構(gòu)設(shè)計中有一條重要的原則叫嚴(yán)出寬進(jìn)，嚴(yán)出意思就是說你提供給其他服務(wù)的東西要盡可能的進(jìn)行嚴(yán)格的校驗。寬進(jìn)就是你調(diào)用別人的接口要寬容，兼容各種情況。比如說你需要考慮別人的節(jié)點down了/api超時/api不可用等等因素。

為了解決這個問題，我們必須要針對具體業(yè)務(wù)，分析依賴類型，是強依賴還是弱依賴，強依賴包裝成自己的服務(wù)異常返回碼/或者直接告訴前端調(diào)用不可用。弱依賴，catch所有異常，無論依賴方發(fā)生什么，不能影響我的接口返回。

此外，我依賴的服務(wù)某段時間內(nèi)接口錯誤率很高，調(diào)用方還在不停的發(fā)送請求，那么就會一直得到錯誤的結(jié)果，這時候這些請求其實是無效的，所以這時候需要客戶端熔斷，不再去調(diào)用服務(wù)方，給服務(wù)方恢復(fù)的時間，等過段時間再去重試，發(fā)現(xiàn)服務(wù)方可用時，再去調(diào)用。

網(wǎng)絡(luò)調(diào)用

網(wǎng)絡(luò)調(diào)用是耗時的，所以我們需要利用池化技術(shù)，復(fù)用連接，比如在單體應(yīng)用中我們需要與數(shù)據(jù)庫連接，會利用到數(shù)據(jù)庫連接池來提高數(shù)據(jù)操作效率。那么微服務(wù)調(diào)用也是這么個道理，我們與其他服務(wù)建議http/tcp連接，也需要建立連接池。另外一個服務(wù)可能會依賴多個微服務(wù)，不能因為和某個服務(wù)之間的連接出了問題，影響到與其他服務(wù)的連接，所以需要做連接池隔離。

服務(wù)間調(diào)用有可能失敗，所以我們需要有重試機制，比如因為網(wǎng)絡(luò)抖動引發(fā)的超時問題，我們可以通過重試提高API的可用性。
但是思考一下壞的情況，某段時間網(wǎng)絡(luò)或者服務(wù)端真的有問題了�？蛻舳顺瑫r時間設(shè)置的很大的話，客戶端等待的時間就會很長，然后再加上重試機制，就會將客戶端的連接占滿，造成客戶端相關(guān)API不可用。
6.微服務(wù)與容器結(jié)合會發(fā)展出新趨勢--Cloud Native，什么是Cloud Native？（可選答）
Cloud Native翻譯為云原生，是Matt Stine提出的一個概念，它是一個思想的集合，包括DevOps、持續(xù)交付（Continuous Delivery）、微服務(wù)（MicroServices）、敏捷基礎(chǔ)設(shè)施（Agile Infrastructure）、康威定律（Conways Law）等，以及根據(jù)商業(yè)能力對公司進(jìn)行重組。Cloud Native既包含技術(shù)（微服務(wù)，敏捷基礎(chǔ)設(shè)施），也包含管理（DevOps，持續(xù)交付，康威定律，重組等）。Cloud Native也可以說是一系列Cloud技術(shù)、企業(yè)管理方法的集合。
作者: incle    時間: 2019-08-26 15:28
微服務(wù)通常由重寫一個模塊開始。要把整個巨石型的應(yīng)用重寫是有很大的風(fēng)險的，也不一定必要。我們向微服務(wù)遷移的時候通常從耦合度最低的模塊或?qū)U展性要求最高的模塊開始，

把它們一個一個剝離出來用敏捷地重寫，可以嘗試最新的技術(shù)和語言和框架，然 后單獨布署。 它通常不依賴其他服務(wù)。微服務(wù)中常用的API Gateway的模式主要目的也不是重用代碼，

而是減少客戶端和服務(wù)間的往來。API gateway模式不等同與Facade模式，我們可以使用如future之類的調(diào)用，甚至返回不完整數(shù)據(jù)。



歡迎光臨 Chinaunix (http://www.72891.cn/) Powered by Discuz! X3.2