theme: fancy
Micro是一個開源的項目致力于簡化微服務開發(fā)朽砰，該項目開始于go-micro(一個用于微服務開發(fā)的Go框架).但是在這之前得运，早在2014年，go-micro還僅僅是一個被設(shè)計用于開發(fā)“k8s即服務”項目的小型庫锅移。
Go Micro 的想法源于將 kubernetes 構(gòu)建為服務的嘗試，它被編寫為一組微服務饱搏，但最終為時過早非剃，并在構(gòu)建后不久就廢棄了。留下的本質(zhì)核心推沸，只要看得夠仔細备绽，你就會發(fā)現(xiàn)少數(shù)包就像一個架構(gòu)的基本內(nèi)容。
2014：起始
剛開始的時候鬓催，微服務是一個熱門話題肺素，但工具很少。人們在他們的組織中談到了這種形式的架構(gòu)和開發(fā)的好處宇驾，但沒有人真正有機會開源他們的工具倍靡，包括我們在 Hailo 的團隊。
我當時注意到了一個模式课舍。一個開發(fā)人員加入了一家公司幾年塌西，幫助公司建立了一個平臺和一套服務，然后離開了筝尾，然后不得不在下一家公司重新開始捡需，沒辦法在之前的工具基礎(chǔ)上繼續(xù)進行開發(fā)。這真讓我沮喪筹淫。特別是因為如果正確的工具作為開源軟件存在站辉，我們就不必不斷地經(jīng)歷這個過程，也許我們會專注于更有趣的問題。
這開始讓我思考如何讓許多公司團結(jié)起來圍繞單一解決方案饰剥。不過我知道一些事情殊霞。 每個組織都有不同的技能、不同的基礎(chǔ)設(shè)施偏好捐川，采用新工具通常是一個很大的障礙脓鹃。
考慮到這一點，我的想法是從一個非常輕量級的微服務開發(fā)框架開始古沥。知道這種方法如何使我們在 Hailo 受益瘸右，感覺它也可能與其他開發(fā)人員產(chǎn)生共鳴。所以在接下來的幾個月里岩齿，我開始研究最終形成初始 go-micro 框架的內(nèi)容太颤。
2015: 開源go-micro
2015 年初，我決定開源 go-micro盹沈×湔拢考慮到我之前從未真正積極地宣傳過一個項目，并且擔心我的代碼質(zhì)量乞封，但我真的很害怕這個想法做裙，但實際上并沒有什么可失去的。Go Micro 感覺像是值得分享的東西肃晚。
與許多開源項目一樣锚贱，我發(fā)布到Hacker News上。它沒有得到多少評論关串，我甚至不記得它在首頁上是否出現(xiàn)過拧廊，但我記得幾天之內(nèi)就達到了 300 顆星！
我沒有快速瀏覽 github 上最早的版本晋修，但幸好當時 Micro 的好朋友和堅定擁護者 Brian Ketelsen fork了它吧碾。你可以在它的github上看看github.com/bketelsen/go-micro，很明顯墓卦，有幾個包概述了微服務通信的方法倦春。
當時的 Go Micro 包括一個用于服務發(fā)現(xiàn)的registry、用于 RPC 和基于 protobuf 的請求處理的server以及一個按名稱調(diào)用這些服務的client趴拧。它甚至包括一個鍵值存儲包溅漾，但我們后來將其刪除以完全專注于通信(我們最近重新添加了它)
Micro:一個微服務工具包
2015 年年中的某個時候，我意識到一個框架是不夠的著榴。一旦你編寫了這些服務添履，就需要有一種方法來訪問它們，為它們提供服務脑又，并通過傳統(tǒng)方式使用它們暮胧。這就是我開始考慮工具包的地方锐借。
在很多情況下，我們看到開源工具試圖解決一個問題往衷。狀態(tài)钞翔、負載平衡、消息傳遞等席舍，但在微服務的情況下享完，您確實需要一個能夠以無縫方式覆蓋所有基礎(chǔ)的整體系統(tǒng)镶柱。本質(zhì)上構(gòu)成了平臺的基礎(chǔ)內(nèi)容。
在這樣的情況下，Micro誕生了猜旬。Micro是作為一個工具包構(gòu)建的猖毫，用于支持微服務平臺的開發(fā)弟胀。它包含一個命令行工具 CLI狸演、Web dashboard和API gateway以及一個非基于 Go 的應用程序的 sidecar。
這種 sidecar模式現(xiàn)在已經(jīng)演變成一種叫做service mesh的東西滑黔，但當時 Netflix 叫做 Prana 的東西笆包，這就是Micro sidecar的基礎(chǔ)。
Micro 和 Go Micro 是我在 2015 年余下時間的全部重點略荡，并且花了很長時間來開發(fā)庵佣，但在那年秋天，一些公司開始在生產(chǎn)中使用它汛兜，這給了我它會在未來幾年蓬勃發(fā)展的希望秧了。
2016:驗證工具
2016 年，我決定是時候再次試水了序无。 讓世界了解 Micro 并吸引一些關(guān)注。我又去了一次Hacker News衡创，只是這一次帝嗡，事情有點不同, Micro登上頭版。
很明顯這里有一些東西璃氢，可能需要這樣一套工具哟玷，我想全職追求它。當時我有機會通過企業(yè)贊助與 Sixt 合作一也。這讓我可以全職在 Micro 上工作巢寡，并將它們用作其功能和開發(fā)的反饋循環(huán)。
我非常感謝 Sixt 提供了這個機會以及它讓 Micro變成什么樣子椰苟。如果沒有他們抑月，目前尚不清楚它是否會取得今天的成就。贊助讓我在幾年的時間里繼續(xù)對這些工具進行迭代舆蝴。 其實3年谦絮。
在那段時間里题诵，Micro 從一個小型開源項目成長為擁有 1k+ 成員、數(shù)千 GitHub star的社區(qū)层皱，但更重要的是在生產(chǎn)環(huán)境中的實際應用性锭。
2019: Micro的演變
回到現(xiàn)在。 今年早些時候叫胖，我有機會將 Micro 從一個單獨的引導式開源項目中提取出來草冈，并將其轉(zhuǎn)變?yōu)橐患绎L險投資公司，有可能在更大規(guī)模上改變微服務開發(fā)的潛力瓮增。
我們還沒有準備好透露所有細節(jié)怎棱，但我要說的是，它使我們能夠開始執(zhí)行我們許多開發(fā)人員所渴望的钉赁。能夠在云端及其他地方構(gòu)建蹄殃、共享和協(xié)作服務，而無需管理基礎(chǔ)設(shè)施你踩。
進展
我們作為一個小團隊在 6 個月內(nèi)取得的進步非常驚人诅岩。在那段時間里committed的次數(shù)比我單獨在 Micro 工作的整整 4 年中committed次數(shù)還要多。
正如你在這里看到的带膜，如果 GitHub star數(shù)是衡量任何事物的標準吩谦，它反映在我們的認知度、流行度和使用率上膝藕。我們最近在 go-micro 框架上通過了 10k 星標記式廷，感覺好像我們才剛剛開始嘗試可能的事情。
您可能可以準確地說出我們從 1 人到 2 人的進展芭挽』希基于這一進展，我對我之前的假設(shè)相當有信心袜爪，即 go-micro 將繼續(xù)成為最主要的 Go 框架蠕趁，并可能在未來十年超越Spring的使用量。
Micro作為一個Runtime
Micro 也取得了顯著進步辛馆，因為我們已經(jīng)從一組稀疏的工具轉(zhuǎn)移到我們現(xiàn)在稱之為microservice runtime environment的東西俺陋。
這背后的想法是將工具包重新定位為構(gòu)建微服務的成熟環(huán)境。一個為底層基礎(chǔ)設(shè)施構(gòu)建成微服務本身提供的可編程抽象層
這張圖片有點舊昙篙，但你會明白這其中的思想腊状。通過抽象底層基礎(chǔ)設(shè)施并將其創(chuàng)建為一組看起來相同、運行相同苔可、感覺相同的服務缴挖，我們最終得到了一個可編程的運行時，它作為所有開發(fā)的基礎(chǔ)焚辅，無論是本地的醇疼，還是在 docker 中 或在云中的 kubernetes 上硕并。
[圖片上傳失敗...(image-4fef8-1630036558260)]
我們還重新定義了開發(fā)和運營之間的界限，讓每一方都可以專注于自己的角色秧荆，而無需理解對方的認知負擔倔毙。在開發(fā)人員的情況下，我們不再需要考慮基礎(chǔ)設(shè)施乙濒，只需要考慮代碼陕赃。
功能集相當廣泛且不斷增長。
Micro作為一個平臺
即使 Micro 作為運行時并擁有用于開發(fā)的 Go 框架解決了很多問題颁股，但這還不夠么库。所以Micro繼續(xù)發(fā)展。僅僅提供構(gòu)建微服務的工具是不夠的甘有，我們還需要提供共享和使用它們的環(huán)境诉儒。在 Micro 中我們?yōu)殚_發(fā)人員構(gòu)建一個全局共享的微服務平臺。
這到底是什么意思亏掀？ 想象一下忱反，當你加入一家公司時，你被賦予工作的平臺滤愕，或者從基礎(chǔ)設(shè)施的角度來看你必須做的所有事情温算，只是為了啟動和運行項目。 我們將把它作為一項服務提供給每個人间影。
用于微服務開發(fā)的完全托管的無服務平臺
為什么注竿？
我對現(xiàn)狀以及開發(fā)人員現(xiàn)在被迫對基礎(chǔ)架構(gòu)和云原生復雜性進行推理的方式感到沮喪。剛?cè)腴T的門檻太高了魂贬。 在云中構(gòu)建服務應該變得更容易巩割，而不是更難。
只需看看云原生景觀……
作為開發(fā)人員不得不對此進行推理是可怕的付燥。 我想做的只是編寫和發(fā)布軟件喂分，但現(xiàn)在我要走一些艱巨的道路，比如容器机蔗、容器編排、docker甘萧、kubernetes萝嘁、服務網(wǎng)格等等。 為什么我不能只編寫代碼并運行它扬卷？
微服務
你可能在想牙言。 好的，那太好了怪得，我相信這個愿景咱枉。無需管理基礎(chǔ)設(shè)施即可進行更簡單的應用程序開發(fā)卑硫，但微服務與此有什么關(guān)系？
我們堅信蚕断，所有形式的大規(guī)模開發(fā)都不可避免地最終成為分布式系統(tǒng)欢伏，而這種開發(fā)模式現(xiàn)在在很大程度上被稱為微服務。
微服務為采用它們的公司帶來了巨大的生產(chǎn)力提升亿乳，并且它們的開發(fā)速度如此之快硝拧，以至于每添加一個新服務，它們在構(gòu)建的系統(tǒng)中都會產(chǎn)生復合價值葛假。
我還認為障陶，開發(fā)人員需要一個平臺，使這種開發(fā)形式能夠蓬勃發(fā)展聊训。 在其中抱究，他們不必考慮基礎(chǔ)設(shè)施，并且他們可以獲得工具带斑，使他們能夠大規(guī)模構(gòu)建軟件鼓寺，而不必擔心運行大型系統(tǒng)。
我想分享的一個極具爭議的例子來自創(chuàng)業(yè)銀行 Monzo遏暴。
Monzo 從第一天起就選擇采用微服務架構(gòu)侄刽。他們知道這種方法需要進行初始操作權(quán)衡，但根據(jù)他們在 Hailo 的經(jīng)歷朋凉，他們知道如果公司在產(chǎn)品方面取得成功州丹，他們需要一個可擴展的平臺來幫助他們 快速成長和移動。
這導致創(chuàng)建了一個現(xiàn)在托管 1500 項服務的平臺杂彭。 這聽起來可能很難解釋墓毒，但是每個開發(fā)人員都能夠使用和重用現(xiàn)有服務的共享平臺是一個非常強大的東西。
不僅如此亲怠，當為您管理平臺時所计，開發(fā)人員可以重新專注于真正重要的事情。 產(chǎn)品和業(yè)務团秽。
解決方案
這種開發(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)境中我們可以在服務上進行協(xié)作见坑，在必要時重用彼此運行的應用程序，并專注于解決更高階的問題捏检。
它會有自己的缺陷和挑戰(zhàn)荞驴，但這樣的平臺帶來的機會是巨大的。 我們想在 Micro 上探索一些東西贯城。
所以這就是我們真正要做的熊楼。 開發(fā)者為開發(fā)者構(gòu)建全球共享服務平臺。 云能犯、kubernetes 等一切的痛苦將不再被感受到鲫骗。 一個我們可以基于go-micro框架構(gòu)建、共享和協(xié)作微服務的環(huán)境踩晶。
結(jié)尾
Micro 的未來涉及快速減少開發(fā)人員在利用云的力量方面的困難执泰，并使他們能夠從任何地方與任何人一起構(gòu)建微服務。
本文來自Asim Aslam
全文使用谷歌翻譯渡蜻。部分翻譯不夠準確术吝，如有更好的翻譯，請在評論區(qū)留言
