什么是Micro？它是微服务发展的未来……

全文共4696字，预计学习时长14分钟Micro的未来

图源：Unsplash

 

 

什么是微服务？什么是Micro？

 

在介绍微服务时，首先得先理解什么是微服务，顾名思义，微服务得从两个方面去理解，什么是"微"、什么是"服务"，

 

微，狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来只需要2个披萨就够了 ）。而所谓服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。

 

Micro则是一个开源项目，致力于简化微服务开发。它开始了一个面向微服务开发的微操作框架。

 

但即便在那之前，go micro还是一个被黑客攻击的小库，它的创建是为了在2014年时开发一个“kubernetes as a service”项目。

 

Go Micro的想法源于将kubernetes构建为一个服务的尝试，它作为一组微服务语言编写，但刚刚面世不久就夭折。但留下来的是其他东西的内核，如果你仔细观察，有几个包看起来像是框架的基础。

 

 

2014: 伊始

 

当时微服务是一个热门话题，但相关工具很少。人们在公司谈到了微服务架构和开发形式的好处，但是没有人真正有机会开源工具，甚至连Hailo的团队也未能做到。

 

那时我注意到一个模式。

 

一位开发人员加入一家公司几年，帮助该公司建立了一个平台和一套服务，但在离开进入下一家公司后，因为没有上一家公司的工具，不得不重新将这个程序走一遍。这让我很沮丧，特别是当我知道如果有正确开源软件，我们就不必继续重复这个过程，而可以把注意力放在更有趣的问题上。更不用说我们至少可以因此节省6到9个月的时间了。

 

这让我开始思考如何让许多公司共同解决一个问题。不过，我知道，每个公司都有不同的技能优势，不同的基础设施偏好，因此采用新的工具往往难度很大。

 

考虑到这一点，我的想法是，从一个非常轻量级但与开发者想法一致的微服务开发框架开始。曾经在Hailo因此受益，这种方式可能也会引起其他开发人员的共鸣。在接下来的几个月里，我开始研究形成go-micro初始框架的要素。

 

 

2015: 开源go-micro

 

2015年初，我决定对go-micro进行开源。因为我从来没有真正积极地宣传过一个项目，我一开始十分害怕，担心代码的质量，但也不会有太多的损失。在我看来，Go-micro是一个值得分享的框架。

 

与许多负责开源项目人员一样，我也在Hacker News发帖，但没有得到任何评论，我甚至不记得我的帖子是否被放在头版，但我记得我的帖子在几天内就有了300颗星！

 

我不知道最初的github是怎么样的，幸好布莱恩·凯特森（Brian Ketelsen），一个Micro的狂热拥护者，对其分流至原始的模样。现在，人们可以在github.com/bketelsen/go-micro清楚地看到概述了微服务通信方法的套装。

 

当时的Go Micro包括一个用于服务发现的注册表、一个用于RPC和基于protobuf的处理请求服务器，以及一个按名称调用这些服务的客户机。之前甚至包含了一个密钥值存储包，但我们后来将其删除，先将重点放在了通信上（最近又重新将其添加）。

 

Micro: 一个微服务工具包

 

2015年中，我意识到只有一个框架是不够的。一旦这编写出这些微服务，就需要有一种方法来对其进行访问，提供服务，并以传统方式使用。因此我开始考虑工具箱的使用。

 

在很多案例中，我们能够看到开源工具是试图去解决问题的，状态、负载平衡、消息传递等，但微服务着实需要一个完整的系统，无缝覆盖所有基础。这些基本上构成平台的基础。

 

就这样，Micro诞生了。Micro作为一个工具包，用于开发微服务平台。它包含一个命令行界面（CLI）、Web仪表板和API网关，以及一个用于非Go应用程序的sidecar模式。这种sidecar模式经过一系列演变，如今被称为“服务网格”。但当时Netflix中包括了Micro sidecar的基础——Prana。

 

“Micro”和“Go Micro”是我接下去在2015年的全部工作重点，花了我很长一段时间来开发。而在那年秋天，一些公司开始将其用到生产中，这给了我希望，在未来几年，此产业可能会繁荣发展。

图源：Unsplash

 

 

2016: 验证工具

 

2016年，我决定是时候再次试水，让全世界都知道并接受Micro。我再次向Hacker News投稿，只是这一次未再石沉大海。https://News.ycombinator.com/item？id=11327679

 

我得到了Hacker News的积极反馈，Micro登上了头版头条。原博如下，感兴趣可点击https://micro.mu/blog/2016/03/20/micro.html

 

很明显，这里可能需要这样一套工具，我想全力以赴去开发。那时我有机会通过公司赞助与Sixt合作，借此我可以在Micro上全职工作，并根据工具包的特性与发展情况，将其作为Micro的反馈环。

 

我非常感谢Sixt给我这个机会，也感谢它让Micro发展的更加成熟。如果没有那次机会，Micro现在会处于何种位置，恐怕还不得而知。这次赞助让我在这3年内，继续以个人名义不断对这些工具进行修复。

 

在那时，Micro从一个小型开源项目发展到拥有上千成员、数千个GitHub之星的社区，但更重要的是，Micro在生产中得到了实际应用。

 

 

2019:演变

 

时光飞逝。今年早些时候，我有机会从一个单独启动的开源项目中发现Micro，将其转变为一家风险投资公司，有可能在更大规模上改变microservices的发展。

 

我们还不能透露所有细节，但我要说的是，这能实现许多开发人员所梦寐以求的——无需管理基础设施就能够在云中和云外进行服务构建、共享和协作。

 

进展

 

作为一个小团队，我们在6个月内取得如此进展已经相当惊人。在这段时间里，我所做的事情比我4年来单独研究Micro所做的还要多。

 

正如这里所示，如果在GitHub获得的星星数量是衡量的标准，那它反映在我们的意识、受欢迎程度和使用情况上。我们最近在go-micro框架上达到了一万颗星星，这种感觉就像我们刚开始一样。

 

你也许能准确地知道我们是如何从1人发展到2人的。基于这一进展，我对之前的假设相当有信心，即go-micro将继续成为最主要的Go框架，并可能在未来十年内超过Spring在全球的使用度。

 

作为运行时

 

Micro也有了显著的进步，因为我们已经从只有一组简略的工具，发展到我们现在所称的微服务运行时环境。

 

真实的想法是重新定向工具包为微服务构建的成熟环境。从而为其构建的底层基础设施提供一个同微服务一般的可编程抽象层。

 

这张图片有点古老，但观点明晰。通过抽象底层基础结构并将其创建为一组服务，它们看起来都是相同的，运行相同，观感相同，我们最终以可编程运行时作为所有开发（无论是local、in docker还是云中的kubernetes）的基础。

 

我们还重新定义了开发和操作之间的界限，使每一方都能专注于自己的角色，而不必去理解另一方。开发人员不必再对基础设施进行解释，进行代码推理即可。

 

特性集相当广泛，并且还在不断扩增。

 

作为平台

 

尽管Micro作为一个运行时和一个Go框架可以解决很多问题，但这还不够。所以Micro还需继续进行革新。仅仅提供构建微服务的工具已经不能满足需求，我们还需要为其提供共享和使用环境。Micro开发人员目前正在构建一个全球微服务共享平台，使开发人员能在此进行技术共享。

 

这到底意味着什么？

 

试想，当你加入一家公司，或者从基础设施的角度来看，你要做的所有事情，都是为了建立和运行这个平台。我们将为每个人提供这项服务。

 

一个用于微服务开发的完全托管的无服务器平台（这是一个很好的平台）。

 

为什么？

 

我对当前的现状感到失望，而现在开发人员不得不对基础设施和原生云复杂性的原因进行解释。入门的门槛太高了，在云中构建服务应该会变得更容易，而不是更难。

 

以下是原生云示意图…

 

要让开发人员必须对此进行解释，这是很可怕的。我只想编写和发布软件，但现在我要完成一些关于container的艰难任务，container orchestration, docker, kubernetes, service mesh等。

 

为什么我不能只是写代码和运行呢？

 

微服务

 

你可能在思考。太棒了，我相信这个观点。更简单的应用程序开发不需要管理基础设施，但微服务与此有什么关系？

 

我们坚信，所有形式的大规模开发都不可避免地以分布式系统的形式结束，而这种开发模式现在主要被称为微服务。

 

微服务大大的提升了运行公司的生产力，且其发展速度如此之快，每增加一项新服务，就在构建的系统中增加了价值。

 

我也相信开发人员需要一个让这种形式的开发蓬勃发展的平台，。其中一种方法是，他们不必对基础设施和提供给他们的工具进行推理，能够不必担心大型系统的操作，大规模地开发软件。

 

分享一个极具争议的例子——初创银行Monzo。

图源：Unsplash

Monzo从建立的第一天起就选择了微服务架构。他们知道这种方法在运营上有最初的折衷方案，但从他们在Hailo的经历来看，他们明白，公司要想在产品方面取得成功，将需要一个可扩展的平台来帮助他们快速成长和发展。

 

这会导致有创建的一个平台需要承载1500个服务。这听起来很难解释，但是一个可供每个开发人员可以消费和再次利用现有的服务的共享平台十分重要和有影响力。

 

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

 

解决方法

 

这种形式的开发很大程度上被能够构建这种系统的大型技术公司所独享。但是，如果这作为大型组织之外的共享系统对每个开发人员开放，会如何。。如果我们能够跨组织和跨团队协作呢。整个行业的发展速度会是怎样的？

 

我认为，在我们所处的几十年里，所有的技术都将以前所未有的速度发展。我们最终会挖掘出互联网的真正潜力。

 

GitHub是这种开源协作与创新的一个典型例子，它极大地减少了托管源代码和创建重用代码环境的痛苦。然而，美中不足的是，这个源代码基本上只在他们自己的平台上使用。

 

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

 

会出现特定的问题和挑战，但这样一个平台带来的机遇是巨大的。还有我们想在Micro中探索的东西——公司。

 

所以这才是我们真正要做的。为开发人员搭建全球共享服务平台。在那里，云, kubernetes还有其他各种软件开发都将变得更加容易。一个基于go-micro框架所构建、共享和协作的微服务环境。

 

 

结语

 

Micro的未来包括迅速减少开发人员在利用云的力量方面的摩擦，并授权他们与任何人从任何地方构建Micro服务。

 

朝着这个目标，大家一起努力奋斗吧~

 

 

留言 点赞 关注

我们一起分享AI学习与发展的干货
欢迎关注全平台AI垂类自媒体 “读芯术”

（添加小编微信：dxsxbb，加入读者圈，一起讨论最新鲜的人工智能科技哦～）