theme: fancy
Micro是一個開源的項目致力于簡化微服務(wù)開發(fā)，該項目開始于go-micro(一個用于微服務(wù)開發(fā)的Go框架).但是在這之前，早在2014年，go-micro還僅僅是一個被設(shè)計用于開發(fā)“k8s即服務(wù)”項目的小型庫。
Go Micro 的想法源于將 kubernetes 構(gòu)建為服務(wù)的嘗試，它被編寫為一組微服務(wù)，但最終為時過早，并在構(gòu)建后不久就廢棄了。留下的本質(zhì)核心，只要看得夠仔細，你就會發(fā)現(xiàn)少數(shù)包就像一個架構(gòu)的基本內(nèi)容。
2014：起始
剛開始的時候，微服務(wù)是一個熱門話題，但工具很少。人們在他們的組織中談到了這種形式的架構(gòu)和開發(fā)的好處，但沒有人真正有機會開源他們的工具，包括我們在 Hailo 的團隊。
我當(dāng)時注意到了一個模式。一個開發(fā)人員加入了一家公司幾年，幫助公司建立了一個平臺和一套服務(wù)，然后離開了，然后不得不在下一家公司重新開始，沒辦法在之前的工具基礎(chǔ)上繼續(xù)進行開發(fā)。這真讓我沮喪。特別是因為如果正確的工具作為開源軟件存在，我們就不必不斷地經(jīng)歷這個過程，也許我們會專注于更有趣的問題。
這開始讓我思考如何讓許多公司團結(jié)起來圍繞單一解決方案。不過我知道一些事情。 每個組織都有不同的技能、不同的基礎(chǔ)設(shè)施偏好，采用新工具通常是一個很大的障礙。
考慮到這一點，我的想法是從一個非常輕量級的微服務(wù)開發(fā)框架開始。知道這種方法如何使我們在 Hailo 受益，感覺它也可能與其他開發(fā)人員產(chǎn)生共鳴。所以在接下來的幾個月里，我開始研究最終形成初始 go-micro 框架的內(nèi)容。
2015: 開源go-micro
2015 年初，我決定開源 go-micro?？紤]到我之前從未真正積極地宣傳過一個項目，并且擔(dān)心我的代碼質(zhì)量，但我真的很害怕這個想法，但實際上并沒有什么可失去的。Go Micro 感覺像是值得分享的東西。
與許多開源項目一樣，我發(fā)布到Hacker News上。它沒有得到多少評論，我甚至不記得它在首頁上是否出現(xiàn)過，但我記得幾天之內(nèi)就達到了 300 顆星！
我沒有快速瀏覽 github 上最早的版本，但幸好當(dāng)時 Micro 的好朋友和堅定擁護者 Brian Ketelsen fork了它。你可以在它的github上看看github.com/bketelsen/go-micro，很明顯，有幾個包概述了微服務(wù)通信的方法。
當(dāng)時的 Go Micro 包括一個用于服務(wù)發(fā)現(xiàn)的registry、用于 RPC 和基于 protobuf 的請求處理的server以及一個按名稱調(diào)用這些服務(wù)的client。它甚至包括一個鍵值存儲包，但我們后來將其刪除以完全專注于通信(我們最近重新添加了它)
Micro:一個微服務(wù)工具包
2015 年年中的某個時候，我意識到一個框架是不夠的。一旦你編寫了這些服務(wù)，就需要有一種方法來訪問它們，為它們提供服務(wù)，并通過傳統(tǒng)方式使用它們。這就是我開始考慮工具包的地方。
在很多情況下，我們看到開源工具試圖解決一個問題。狀態(tài)、負載平衡、消息傳遞等，但在微服務(wù)的情況下，您確實需要一個能夠以無縫方式覆蓋所有基礎(chǔ)的整體系統(tǒng)。本質(zhì)上構(gòu)成了平臺的基礎(chǔ)內(nèi)容。
在這樣的情況下，Micro誕生了。Micro是作為一個工具包構(gòu)建的，用于支持微服務(wù)平臺的開發(fā)。它包含一個命令行工具 CLI、Web dashboard和API gateway以及一個非基于 Go 的應(yīng)用程序的 sidecar。
這種 sidecar模式現(xiàn)在已經(jīng)演變成一種叫做service mesh的東西，但當(dāng)時 Netflix 叫做 Prana 的東西，這就是Micro sidecar的基礎(chǔ)。
Micro 和 Go Micro 是我在 2015 年余下時間的全部重點，并且花了很長時間來開發(fā)，但在那年秋天，一些公司開始在生產(chǎn)中使用它，這給了我它會在未來幾年蓬勃發(fā)展的希望。
2016:驗證工具
2016 年，我決定是時候再次試水了。 讓世界了解 Micro 并吸引一些關(guān)注。我又去了一次Hacker News，只是這一次，事情有點不同, Micro登上頭版。
很明顯這里有一些東西，可能需要這樣一套工具，我想全職追求它。當(dāng)時我有機會通過企業(yè)贊助與 Sixt 合作。這讓我可以全職在 Micro 上工作，并將它們用作其功能和開發(fā)的反饋循環(huán)。
我非常感謝 Sixt 提供了這個機會以及它讓 Micro變成什么樣子。如果沒有他們，目前尚不清楚它是否會取得今天的成就。贊助讓我在幾年的時間里繼續(xù)對這些工具進行迭代。 其實3年。
在那段時間里，Micro 從一個小型開源項目成長為擁有 1k+ 成員、數(shù)千 GitHub star的社區(qū)，但更重要的是在生產(chǎn)環(huán)境中的實際應(yīng)用。
2019: Micro的演變
回到現(xiàn)在。 今年早些時候，我有機會將 Micro 從一個單獨的引導(dǎo)式開源項目中提取出來，并將其轉(zhuǎn)變?yōu)橐患绎L(fēng)險投資公司，有可能在更大規(guī)模上改變微服務(wù)開發(fā)的潛力。
我們還沒有準備好透露所有細節(jié)，但我要說的是，它使我們能夠開始執(zhí)行我們許多開發(fā)人員所渴望的。能夠在云端及其他地方構(gòu)建、共享和協(xié)作服務(wù)，而無需管理基礎(chǔ)設(shè)施。
進展
我們作為一個小團隊在 6 個月內(nèi)取得的進步非常驚人。在那段時間里committed的次數(shù)比我單獨在 Micro 工作的整整 4 年中committed次數(shù)還要多。
正如你在這里看到的，如果 GitHub star數(shù)是衡量任何事物的標準，它反映在我們的認知度、流行度和使用率上。我們最近在 go-micro 框架上通過了 10k 星標記，感覺好像我們才剛剛開始嘗試可能的事情。
您可能可以準確地說出我們從 1 人到 2 人的進展。基于這一進展，我對我之前的假設(shè)相當(dāng)有信心，即 go-micro 將繼續(xù)成為最主要的 Go 框架，并可能在未來十年超越Spring的使用量。
Micro作為一個Runtime
Micro 也取得了顯著進步，因為我們已經(jīng)從一組稀疏的工具轉(zhuǎn)移到我們現(xiàn)在稱之為microservice runtime environment的東西。
這背后的想法是將工具包重新定位為構(gòu)建微服務(wù)的成熟環(huán)境。一個為底層基礎(chǔ)設(shè)施構(gòu)建成微服務(wù)本身提供的可編程抽象層
這張圖片有點舊，但你會明白這其中的思想。通過抽象底層基礎(chǔ)設(shè)施并將其創(chuàng)建為一組看起來相同、運行相同、感覺相同的服務(wù)，我們最終得到了一個可編程的運行時，它作為所有開發(fā)的基礎(chǔ)，無論是本地的，還是在 docker 中 或在云中的 kubernetes 上。
[圖片上傳失敗...(image-4fef8-1630036558260)]
我們還重新定義了開發(fā)和運營之間的界限，讓每一方都可以專注于自己的角色，而無需理解對方的認知負擔(dān)。在開發(fā)人員的情況下，我們不再需要考慮基礎(chǔ)設(shè)施，只需要考慮代碼。
功能集相當(dāng)廣泛且不斷增長。
Micro作為一個平臺
即使 Micro 作為運行時并擁有用于開發(fā)的 Go 框架解決了很多問題，但這還不夠。所以Micro繼續(xù)發(fā)展。僅僅提供構(gòu)建微服務(wù)的工具是不夠的，我們還需要提供共享和使用它們的環(huán)境。在 Micro 中我們?yōu)殚_發(fā)人員構(gòu)建一個全局共享的微服務(wù)平臺。
這到底是什么意思？ 想象一下，當(dāng)你加入一家公司時，你被賦予工作的平臺，或者從基礎(chǔ)設(shè)施的角度來看你必須做的所有事情，只是為了啟動和運行項目。 我們將把它作為一項服務(wù)提供給每個人。
用于微服務(wù)開發(fā)的完全托管的無服務(wù)平臺
為什么？
我對現(xiàn)狀以及開發(fā)人員現(xiàn)在被迫對基礎(chǔ)架構(gòu)和云原生復(fù)雜性進行推理的方式感到沮喪。剛?cè)腴T的門檻太高了。 在云中構(gòu)建服務(wù)應(yīng)該變得更容易，而不是更難。
只需看看云原生景觀……
作為開發(fā)人員不得不對此進行推理是可怕的。 我想做的只是編寫和發(fā)布軟件，但現(xiàn)在我要走一些艱巨的道路，比如容器、容器編排、docker、kubernetes、服務(wù)網(wǎng)格等等。 為什么我不能只編寫代碼并運行它？
微服務(wù)
你可能在想。 好的，那太好了，我相信這個愿景。無需管理基礎(chǔ)設(shè)施即可進行更簡單的應(yīng)用程序開發(fā)，但微服務(wù)與此有什么關(guān)系？
我們堅信，所有形式的大規(guī)模開發(fā)都不可避免地最終成為分布式系統(tǒng)，而這種開發(fā)模式現(xiàn)在在很大程度上被稱為微服務(wù)。
微服務(wù)為采用它們的公司帶來了巨大的生產(chǎn)力提升，并且它們的開發(fā)速度如此之快，以至于每添加一個新服務(wù)，它們在構(gòu)建的系統(tǒng)中都會產(chǎn)生復(fù)合價值。
我還認為，開發(fā)人員需要一個平臺，使這種開發(fā)形式能夠蓬勃發(fā)展。 在其中，他們不必考慮基礎(chǔ)設(shè)施，并且他們可以獲得工具，使他們能夠大規(guī)模構(gòu)建軟件，而不必擔(dān)心運行大型系統(tǒng)。
我想分享的一個極具爭議的例子來自創(chuàng)業(yè)銀行 Monzo。
Monzo 從第一天起就選擇采用微服務(wù)架構(gòu)。他們知道這種方法需要進行初始操作權(quán)衡，但根據(jù)他們在 Hailo 的經(jīng)歷，他們知道如果公司在產(chǎn)品方面取得成功，他們需要一個可擴展的平臺來幫助他們 快速成長和移動。
這導(dǎo)致創(chuàng)建了一個現(xiàn)在托管 1500 項服務(wù)的平臺。 這聽起來可能很難解釋，但是每個開發(fā)人員都能夠使用和重用現(xiàn)有服務(wù)的共享平臺是一個非常強大的東西。
不僅如此，當(dāng)為您管理平臺時，開發(fā)人員可以重新專注于真正重要的事情。 產(chǎn)品和業(yè)務(wù)。
解決方案
這種開發(fā)形式在很大程度上孤立于能夠構(gòu)建此類系統(tǒng)的大型技術(shù)公司。 但是，如果每個開發(fā)人員都可以將其作為這些大型組織之外的共享系統(tǒng)使用呢？ 如果我們能夠跨組織和跨團隊協(xié)作會怎樣。 我們作為一個行業(yè)的整體發(fā)展速度如何？
我會爭辯說，所有技術(shù)的進步都會比我們之前的幾十年里的任何時候都快。 我們將最終捕捉到互聯(lián)網(wǎng)的真正潛力。
GitHub 是這種開源協(xié)作和創(chuàng)新的一個典型例子，它極大地減少了托管源代碼的痛苦，并為重用代碼創(chuàng)造了環(huán)境。 然而，只有一個但是，這個源代碼主要位于他們的平臺上。
如果我們不只是共享代碼并在孤島中運行它，而是共享一個軟件開發(fā)環(huán)境，在該環(huán)境中我們可以在服務(wù)上進行協(xié)作，在必要時重用彼此運行的應(yīng)用程序，并專注于解決更高階的問題。
它會有自己的缺陷和挑戰(zhàn)，但這樣的平臺帶來的機會是巨大的。 我們想在 Micro 上探索一些東西。
所以這就是我們真正要做的。 開發(fā)者為開發(fā)者構(gòu)建全球共享服務(wù)平臺。 云、kubernetes 等一切的痛苦將不再被感受到。 一個我們可以基于go-micro框架構(gòu)建、共享和協(xié)作微服務(wù)的環(huán)境。
結(jié)尾
Micro 的未來涉及快速減少開發(fā)人員在利用云的力量方面的困難，并使他們能夠從任何地方與任何人一起構(gòu)建微服務(wù)。
本文來自Asim Aslam
全文使用谷歌翻譯。部分翻譯不夠準確，如有更好的翻譯，請在評論區(qū)留言
