---

theme: fancy

Micro是一个开源的项目致力于简化微服务开发，该项目开始于go-micro(一个用于微服务开发的Go框架).但是在这之前，早在2014年，go-micro还仅仅是一个被设计用于开发“k8s即服务”项目的小型库。

Go Micro 的想法源于将 kubernetes 构建为服务的尝试，它被编写为一组微服务，但最终为时过早，并在构建后不久就废弃了。留下的本质核心，只要看得够仔细，你就会发现少数包就像一个架构的基本内容。

2014：起始

刚开始的时候，微服务是一个热门话题，但工具很少。人们在他们的组织中谈到了这种形式的架构和开发的好处，但没有人真正有机会开源他们的工具，包括我们在 Hailo 的团队。

我当时注意到了一个模式。一个开发人员加入了一家公司几年，帮助公司建立了一个平台和一套服务，然后离开了，然后不得不在下一家公司重新开始，没办法在之前的工具基础上继续进行开发。这真让我沮丧。特别是因为如果正确的工具作为开源软件存在，我们就不必不断地经历这个过程，也许我们会专注于更有趣的问题。

这开始让我思考如何让许多公司团结起来围绕单一解决方案。不过我知道一些事情。 每个组织都有不同的技能、不同的基础设施偏好，采用新工具通常是一个很大的障碍。

考虑到这一点，我的想法是从一个非常轻量级的微服务开发框架开始。知道这种方法如何使我们在 Hailo 受益，感觉它也可能与其他开发人员产生共鸣。所以在接下来的几个月里，我开始研究最终形成初始 go-micro 框架的内容。

2015: 开源go-micro

2015 年初，我决定开源 go-micro。考虑到我之前从未真正积极地宣传过一个项目，并且担心我的代码质量，但我真的很害怕这个想法，但实际上并没有什么可失去的。Go Micro 感觉像是值得分享的东西。

与许多开源项目一样，我发布到Hacker News上。它没有得到多少评论，我甚至不记得它在首页上是否出现过，但我记得几天之内就达到了 300 颗星！

我没有快速浏览 github 上最早的版本，但幸好当时 Micro 的好朋友和坚定拥护者 Brian Ketelsen fork了它。你可以在它的github上看看github.com/bketelsen/go-micro，很明显，有几个包概述了微服务通信的方法。

当时的 Go Micro 包括一个用于服务发现的registry、用于 RPC 和基于 protobuf 的请求处理的server以及一个按名称调用这些服务的client。它甚至包括一个键值存储包，但我们后来将其删除以完全专注于通信(我们最近重新添加了它)

Micro:一个微服务工具包

2015 年年中的某个时候，我意识到一个框架是不够的。一旦你编写了这些服务，就需要有一种方法来访问它们，为它们提供服务，并通过传统方式使用它们。这就是我开始考虑工具包的地方。

在很多情况下，我们看到开源工具试图解决一个问题。状态、负载平衡、消息传递等，但在微服务的情况下，您确实需要一个能够以无缝方式覆盖所有基础的整体系统。本质上构成了平台的基础内容。

在这样的情况下，Micro诞生了。Micro是作为一个工具包构建的，用于支持微服务平台的开发。它包含一个命令行工具 CLI、Web dashboard和API gateway以及一个非基于 Go 的应用程序的 sidecar。
这种 sidecar模式现在已经演变成一种叫做service mesh的东西，但当时 Netflix 叫做 Prana 的东西，这就是Micro sidecar的基础。

Micro 和 Go Micro 是我在 2015 年余下时间的全部重点，并且花了很长时间来开发，但在那年秋天，一些公司开始在生产中使用它，这给了我它会在未来几年蓬勃发展的希望。

2016:验证工具

2016 年，我决定是时候再次试水了。 让世界了解 Micro 并吸引一些关注。我又去了一次Hacker News，只是这一次，事情有点不同, Micro登上头版。

很明显这里有一些东西，可能需要这样一套工具，我想全职追求它。当时我有机会通过企业赞助与 Sixt 合作。这让我可以全职在 Micro 上工作，并将它们用作其功能和开发的反馈循环。

我非常感谢 Sixt 提供了这个机会以及它让 Micro变成什么样子。如果没有他们，目前尚不清楚它是否会取得今天的成就。赞助让我在几年的时间里继续对这些工具进行迭代。 其实3年。

在那段时间里，Micro 从一个小型开源项目成长为拥有 1k+ 成员、数千 GitHub star的社区，但更重要的是在生产环境中的实际应用。

2019: Micro的演变

回到现在。 今年早些时候，我有机会将 Micro 从一个单独的引导式开源项目中提取出来，并将其转变为一家风险投资公司，有可能在更大规模上改变微服务开发的潜力。

我们还没有准备好透露所有细节，但我要说的是，它使我们能够开始执行我们许多开发人员所渴望的。能够在云端及其他地方构建、共享和协作服务，而无需管理基础设施。

进展

我们作为一个小团队在 6 个月内取得的进步非常惊人。在那段时间里committed的次数比我单独在 Micro 工作的整整 4 年中committed次数还要多。

正如你在这里看到的，如果 GitHub star数是衡量任何事物的标准，它反映在我们的认知度、流行度和使用率上。我们最近在 go-micro 框架上通过了 10k 星标记，感觉好像我们才刚刚开始尝试可能的事情。

image.png

您可能可以准确地说出我们从 1 人到 2 人的进展。基于这一进展，我对我之前的假设相当有信心，即 go-micro 将继续成为最主要的 Go 框架，并可能在未来十年超越Spring的使用量。

Micro作为一个Runtime

Micro 也取得了显着进步，因为我们已经从一组稀疏的工具转移到我们现在称之为microservice runtime environment的东西。

这背后的想法是将工具包重新定位为构建微服务的成熟环境。一个为底层基础设施构建成微服务本身提供的可编程抽象层

这张图片有点旧，但你会明白这其中的思想。通过抽象底层基础设施并将其创建为一组看起来相同、运行相同、感觉相同的服务，我们最终得到了一个可编程的运行时，它作为所有开发的基础，无论是本地的，还是在 docker 中 或在云中的 kubernetes 上。

[图片上传失败...(image-4fef8-1630036558260)]

我们还重新定义了开发和运营之间的界限，让每一方都可以专注于自己的角色，而无需理解对方的认知负担。在开发人员的情况下，我们不再需要考虑基础设施，只需要考虑代码。

功能集相当广泛且不断增长。

image.png

Micro作为一个平台

即使 Micro 作为运行时并拥有用于开发的 Go 框架解决了很多问题，但这还不够。所以Micro继续发展。仅仅提供构建微服务的工具是不够的，我们还需要提供共享和使用它们的环境。在 Micro 中我们为开发人员构建一个全局共享的微服务平台。

这到底是什么意思？ 想象一下，当你加入一家公司时，你被赋予工作的平台，或者从基础设施的角度来看你必须做的所有事情，只是为了启动和运行项目。 我们将把它作为一项服务提供给每个人。

用于微服务开发的完全托管的无服务平台

为什么？

我对现状以及开发人员现在被迫对基础架构和云原生复杂性进行推理的方式感到沮丧。刚入门的门槛太高了。 在云中构建服务应该变得更容易，而不是更难。

只需看看云原生景观……

image.png

作为开发人员不得不对此进行推理是可怕的。 我想做的只是编写和发布软件，但现在我要走一些艰巨的道路，比如容器、容器编排、docker、kubernetes、服务网格等等。 为什么我不能只编写代码并运行它？

微服务

你可能在想。 好的，那太好了，我相信这个愿景。无需管理基础设施即可进行更简单的应用程序开发，但微服务与此有什么关系？

我们坚信，所有形式的大规模开发都不可避免地最终成为分布式系统，而这种开发模式现在在很大程度上被称为微服务。

微服务为采用它们的公司带来了巨大的生产力提升，并且它们的开发速度如此之快，以至于每添加一个新服务，它们在构建的系统中都会产生复合价值。

我还认为，开发人员需要一个平台，使这种开发形式能够蓬勃发展。 在其中，他们不必考虑基础设施，并且他们可以获得工具，使他们能够大规模构建软件，而不必担心运行大型系统。

我想分享的一个极具争议的例子来自创业银行 Monzo。

Monzo 从第一天起就选择采用微服务架构。他们知道这种方法需要进行初始操作权衡，但根据他们在 Hailo 的经历，他们知道如果公司在产品方面取得成功，他们需要一个可扩展的平台来帮助他们 快速成长和移动。

这导致创建了一个现在托管 1500 项服务的平台。 这听起来可能很难解释，但是每个开发人员都能够使用和重用现有服务的共享平台是一个非常强大的东西。

不仅如此，当为您管理平台时，开发人员可以重新专注于真正重要的事情。 产品和业务。

解决方案

这种开发形式在很大程度上孤立于能够构建此类系统的大型技术公司。 但是，如果每个开发人员都可以将其作为这些大型组织之外的共享系统使用呢？ 如果我们能够跨组织和跨团队协作会怎样。 我们作为一个行业的整体发展速度如何？

我会争辩说，所有技术的进步都会比我们之前的几十年里的任何时候都快。 我们将最终捕捉到互联网的真正潜力。

GitHub 是这种开源协作和创新的一个典型例子，它极大地减少了托管源代码的痛苦，并为重用代码创造了环境。 然而，只有一个但是，这个源代码主要位于他们的平台上。

如果我们不只是共享代码并在孤岛中运行它，而是共享一个软件开发环境，在该环境中我们可以在服务上进行协作，在必要时重用彼此运行的应用程序，并专注于解决更高阶的问题。

它会有自己的缺陷和挑战，但这样的平台带来的机会是巨大的。 我们想在 Micro 上探索一些东西。

所以这就是我们真正要做的。 开发者为开发者构建全球共享服务平台。 云、kubernetes 等一切的痛苦将不再被感受到。 一个我们可以基于go-micro框架构建、共享和协作微服务的环境。

结尾

Micro 的未来涉及快速减少开发人员在利用云的力量方面的困难，并使他们能够从任何地方与任何人一起构建微服务。

本文来自Asim Aslam

全文使用谷歌翻译。部分翻译不够准确，如有更好的翻译，请在评论区留言