Micro 3.0是一个云原生开发平台

这是Micro3.0(更为人熟知的名字是M3O)的正式发布--这是一个云本地开发平台。我们的3.0版本是对现有工具的重大重构和整合，从开发人员的角度解决了构建、运行、管理和消费的整个工作流程。

请继续阅读以了解更多信息，或者直接转到最新版本。访问m3o.com获取托管服务。

Micro专注于后端开发人员的工作效率。很明显，在过去的几年里，云已经变得非常复杂。Micro试图通过为分布式系统开发提炼出几个原语，从而从混乱中创造秩序。

你为什么要关心呢？如果你正在阅读这篇文章，你肯定遇到过基础设施管理的单调乏味的本质，在AWS上争论Kubernetes集群，或者在开始构建产品之前需要做成千上万的事情来拼凑一个平台。我们认为我们已经找到了这个问题的解决方案，就像Android为Mobile提供的解决方案一样。如果你想了解更多，请继续阅读。

Micro最初是一个用于微服务开发的工具包，包含一个API网关、Web仪表板和CLI，用于与使用Go RPC框架构建的服务进行交互。当时的感觉是，让任何人再次购买PaaS都将是一场失败的战斗。因此，我们选择围绕一个RPC框架编写单一用途的工具，认为它可以让人们逐步采用它，直到他们发现需要一个平台。它真的是直截了当的，直到它不是。

有一个简单的Go框架，外加一些周边组件来查询和与它们交互，但就像任何长期存在的项目一样，当我们试图解决无法用瑞士军刀完成的平台体验时，复杂性增加了。回购激增，涌现出许多独立的图书馆。对于创作者来说，这些都是为了什么是显而易见的，但对用户来说，这只是认知负荷过重。

2019年，我们经历了所有这些图书馆的整合，这带来了巨大的帮助，但仍然存在一个悬而未决的问题。微型和微型有什么不同？这是一个很好的问题，我们以前已经谈过了。我们把Go-Micro看作一个框架，把Micro看作一个工具箱，但这些话基本上是空洞和无意义的，因为协同工作的多个项目确实需要一个有意义的清晰故事，而我们没有这样的故事。

在2020年，我们希望纠正这一点，但首先让我们来谈谈平台。

5年前，随着集装箱和集装箱编排占据了中心舞台，“本地云”工具大量涌现，世界呈现爆炸式增长。更具体地说，Docker和Kubernetes重新定义了技术版图，并更有意识地转向在云中构建软件。

早在2015年，Micro就采取了前瞻性的观点。很明显，分布式系统和云原生将在未来几年成为后端服务开发的主导模式，但不清楚的是，我们还会花多长时间与各种工具争论不休，比如docker、Kubernetes、GRPC、istio和其他所有工具。感觉就像我们正在重建堆栈，还没有真正准备好谈论它的开发方面。

事实上，在那个时候，人们主要是想把所有这些工具上的轮胎踢开，然后把东西拼凑在一起。自己运行Kubernetes变得非常流行，甚至将服务网格作为解决所有分布式系统问题的圣杯。我们中的许多人已经意识到，尽管所有这些技术都很有趣，但它实际上并没有解决开发问题。

我们已经到了托管Kubernetes的地步，甚至像Google Cloud Run或DigitalOcean App Platform这样的东西，但这些都不利于云原生时代的开发模式。我们对现有开发者体验的挫败感与日俱增，Micro感觉可以解决所有这些问题，但前提是我们必须采取彻底的措施来彻底改革它。

我们认为PaaS 3.0不仅仅是运行您的容器或源代码，而是封装了整个开发人员的体验，包括为云编写代码的模型。在此基础上，Micro 3.0(又名M3O)是一个云本地开发平台。

什么是原生云？为云构建意味着什么？什么是云服务？

原生云基本上是为在云中运行而构建的东西的描述性术语。就这样。这不是魔术，它可能听起来像一个流行语，但事实是，它只是意味着，这款软件是为在云中运行而构建的。这与我们以前建造的方式有什么不同？云背后的理念是，它是短暂的、可伸缩的，所有东西都可以通过API访问。

我们对在云中运行的服务的期望是，它们大多是无状态的，利用外部服务进行持久化，它们由名称而不是IP地址标识，并且它们本身提供一个可以被多个客户端使用的API，例如web、移动和CLI或其他服务。

云原生应用是水平可扩展的，并在域边界内运行，域边界将它们划分为独立的应用，这些应用通过其API在网络上通信，而不是作为一个单一实体。我们认为云服务需要一种完全不同的软件创建方法，这也是Micro 3.0设计时考虑到这一点的原因。

Micro 3.0(M3O)将Micro重新设想为云本地开发的平台。那是什么意思？我们认为它是PaaS 3.0，一个从源代码到运行甚至更远的完整解决方案。Micro已经从仅仅是一个Go框架转变为融合了独立的服务器和托管平台。我们的托管服务被称为M3O，这是对Micro 3.0或M[ICR]o的致敬，无论你想从哪种方式来看待它。

另一种思考方式。正如Git之于GitHub，Micro之于M3O平台。让我们深入研究一下吧。

服务器是我们对编写分布式系统时可能需要的云基础设施和底层系统的抽象。服务器将所有这些关注点封装为GRPC服务，您可以通过任何语言进行查询。这里的目标是说开发人员并不真的需要考虑基础设施，但他们真正需要的是用于构建分布式系统的设计模式和原语。

身份验证：验证其身份验证或授权是否为系统的一部分。创建JWT令牌，定义访问规则，使用一个系统以简单直接的方式管理一切。无论是针对用户还是服务。

配置：动态配置管理允许您存储需要更新的相关配置，而无需重启服务。将API密钥和与业务逻辑相关的配置添加到安全配置服务中，并让您的服务获取更改。

Key-Value Storage：我们专注于微服务开发的最佳实践，这意味着让服务基本上保持无状态。为此，我们在平台上提供持久存储。Key-Value允许您快速编写代码并以您关心的格式存储数据。

事件流：分布式系统从根本上需要一个事件驱动的体系结构来分解它们之间的紧密依赖关系。通过使用事件流和pubSub，您可以异步发布和订阅相关事件。

服务注册：Micro和M3O提供了服务发现功能，因此您可以浏览服务目录来浏览您的服务API，并使您能够按名称查询服务。Micro完全是关于微服务和多服务开发的。

服务网络：因为您不希望将这些服务名称解析为地址和处理负载平衡方面，所以服务器在一个“服务网格”中烘焙，它将处理您的服务间请求(作为GRPC)并路由到适当的实例。

身份代理：对于通过CLI和其他方式使用GRPC的外部请求，我们包括一个单独的身份代理。这使您能够使用有效的身份验证凭据从本地计算机或其他任何地方进行查询，并使其无缝工作，就像您在平台本身中一样。

API Gateway：最后还有一个API网关，可以通过HTTP自动向外界公开您的服务。在内部使用GRPC编写服务到服务是有意义的，但归根结底，我们希望构建通过HTTP从客户端使用的API。

该服务器通过HTTP API和GRPC代理提供服务间通信和两种外部通信方式，但当客户端的用户体验正常时，这种体验会更好。现在我们有两种方法可以做到这一点。

命令行：CLI提供了一种通过代理通过GRPC请求与服务器对话的方便简单的方式。最方便的命令都是内置的，但是您编写的每个服务也会为每个端点获得漂亮的动态生成的命令。

GRPC SDK：服务器中的所有服务都可以通过GRPC访问。我们正在为服务器本身生成客户端代码，这样您就可以从任何语言访问它们。这样就可以在客户端获得广泛的体验，而不必为每种语言手工创建库。

Web界面：即将推出的是一个动态生成的Web界面，它可以通过浏览器为您的任何服务创建一个简单的查询机制。我们有http API、GRPC代理和命令行界面，但感觉浏览器也需要一些改进。

从我们从事Go-Micro的工作中，我们真正明白了一件事，那就是开发者的体验真的很重要。我们认为Go是云的主导语言，并相信云中的大多数后端服务都将是用Go编写的。出于这个原因，我们继续包括服务框架，它充当构建服务和访问服务器底层系统的框架。

服务框架为服务器的所有功能提供了预初始化的包，并创建了一个方便的初始化器，用于从service.New开始定义您自己的服务。服务有一个名称，即端点，它包含自己的服务器和用于查询其他服务的客户端。该框架为您做了足够的工作，但随后又试图避开您的障碍，因此剩下的事情就由您决定了。

包主导入("；github.com/Micro/Micro/v3/SERVICE"；"；github.com/micro/micro/v3/service/logger"；"；github.com/micro/services/helloworld/handler"；)Func Main(){//创建服务srv：=SERVICE。新(服务。名称("；HelloWorld"；)，)//注册处理程序服务器。句柄(新的(处理程序。HelloWorld))//如果err：=srv，则运行该服务。Run()；err！=nil{记录器。致命(错误)}}。

当您想要使用像Config服务这样的东西时，只需像这样导入它即可。

根据我们的经验，编写软件并不局限于单一的环境。大多数时候，我们都在进行某种形式的地方开发，然后推动试运行，然后再进行生产。我们真的看不到工具能有效地捕获该工作流。考虑如何做到这一点，现在我们已经将环境构建为一流的系统。

我们的目标是真正引导本地开发平台的流量，将其作为任何后端服务开发的生命周期。首先在本地运行服务器，编写代码并使其正常工作。将其发送到开发环境进行进一步测试，但也是为了与其他人协作并公开服务。然后，如果您对可伸缩且受支持的生产环境感兴趣，请为平台环境买单。就这样。

#查看环境smicro env#设置环境microenv set dev#添加新环境microenv add foobar proxy.foo.com：443。

Micro并不局限于我们的内置环境。您可以随心所欲地添加其他用户。

当地的环境就是这样，你当地的笔记本电脑。这是开发的起点，通常这需要您运行各种疯狂的基础设施。Micro专注于提供可插拔的抽象作为GRPC服务，因此您的服务只需与Micro直接对话GRPC，我们就会对您隐藏细节。在本地，这意味着我们正在尽最大努力使用MDN、文件存储等东西。

我们几乎让从本地开始做起变得非常简单。您只需运行一个命令。

这将引导您需要的所有服务，并允许您构建在任何运行Micro as a Service的云环境中看起来都相同的服务。

这在本地可能是空白的，但稍后您将了解名称空间隔离是如何工作的。

“dev”环境是一个免费的云托管环境，提供Micro 3.0即服务。我们在过去几年中了解到的是，开源是不够的。市面上有一些很棒的开源工具，但是一旦我们开始部署，就会有太多的障碍需要克服。开发环境为每个人提供了在几分钟内启动和运行的能力，这些工具与您在云中用于本地开发的工具相同。

您所要做的就是将env设置为‘dev’，并像本地一样使用它。

如果您使用的是dev环境，则URL是*.m3o.dev。有关更多详细信息，请访问m3o.dev。

“平台”环境是一个安全、可扩展且受支持的生产环境，您可以在其中运行面向客户的服务和产品。这是一个付费级别，最初的资源限制是开发人员的两倍，包括SLA和SLA的Sack&；电子邮件支持。您可以将其视为您在任何工作场所都熟悉的生产平台。

我们使用Local、Dev和Platform的目标是调用我们都知道并期望成为真正产品的工作流程。这些都是完全独立的环境，它们的管理方式也与M3O完全相同。

随着Kubernetes这样的系统的出现以及对云计算的推动，我们可以看到，确实有必要转向共享资源使用。云并不便宜，我们也不需要运行单独的Kubernetes集群。事实上，如果我们可以分享这一点，那不是很棒吗？嗯，Micro正在做这件事。我们使用与Kubernetes称为命名空间的逻辑相同的逻辑构建多租户。

我们已经在本地映射了同样的体验，因此您可以为本地开发人员提供基本形式的命名空间，但我们主要使用的是生产中的Kubernetes命名空间，以及用于身份验证、存储、配置、事件流等的一整套自定义编写的隔离机制，因此Micro 3.0可用于托管多个租户。

无论您是否决定自行托管和共享集群以用于开发、试运行和生产，我们都认为多租户需要在2020年成为事实上的标准。它是如何在实践中发挥作用的。每个租户获取一个名称空间。该命名空间在每个子系统中都有自己的独立用户和资源集。当您作为用户或服务发出任何请求时，会同时传递一个JWT令牌，这样底层系统就可以路由到适当的资源。

一旦您注册了开发环境，您的命名空间就会为您设置好。您可以使用以下命令获取它。

当您使用任何类型的CLI命令时，您的命名空间和身份验证令牌会自动注入到请求中，包括刷新这些令牌。在Micro上运行的任何服务都会发生同样的情况。如果您想使用http API或公共API url[api.m3o.dev]，那么继续抓取您的命名空间，并将头文件设置为Micro-Namespace。

此外，每个名称空间都有自己的定制域，因此foobar名称空间成为foobar.m3o.dev，而HelloWorld服务的路由是foobar.m3o.dev/Helloworld。

Micro是在对现有工具感到失望的基础上建立起来的。很长一段时间以来，我一直在说的一件事是，我只想在一个命令中“从源到运行”。对于Heroku，我们在某种程度上得到了这一点，但它真的让我们失去了太多。早在2010年，Heroku就专注于单片铁路的开发。从那以后，我真的说过，Heroku拿走了太多，AWS回报了太多。我们需要一些介于两者之间的东西。

Micro可以从本地目录或GitHub、GitLab或Bitbucket上托管的repo中获取源代码。在一个命令中，它将上传或从相关位置获取，将其打包为容器并运行。就这样。仅在一个命令中运行源代码。不再需要处理管道，不再费力修改容器和容器注册表。编写一些代码并运行它。

源代码到运行是很酷的。这就是PaaS的真正用途，但即使是在新的PaaS热潮中，也真正缺乏的一件事是开发模型。正如我所回避的那样，Heroku拿走了太多，AWS回馈了太多。我们在寻找一个令人满意的折中方案。它不需要我们依赖于VM或容器，但另一方面也不会将我们局限于单一的开发。

Micro一直专注于分布式系统开发或微服务的实践。将大型整体式应用程序分解为做好一件事的较小的独立服务的想法。要做到这一点，我们认为你真的必须将开发模型融入到平台中。

我们包含的是服务的概念，它包含用于处理请求和查询其他服务的客户端和服务器。我们的重点是围绕API定义的协议buf和使用GRPC进行网络分层的标准化。

不仅如此，我们还包括用于事件流架构的pubsub，以及NoSQL键值存储和动态配置管理等其他功能。我们相信，开始构建微服务和分布式系统需要特定的原语，而这正是Micro希望提供的。

我们从GO框架Go-Micro的开发中学到的一个重要经验是，对于我们为其开发的每个平台(如Web、移动等)，我们大多使用一种单一的语言。云也不会有什么不同。我们支持Go for the Cloud，但认为需要有一个消费Go服务的生态系统，而且可能会扩展到无法使用Python、Java、Ruby、Ruust或Javascript的地方。因为Micro的接口是GRPC，所以我们代码生成GRPC客户端，并允许任何语言利用Micro服务器。

过去，多语言客户端都是费力手工制作的，我们从构建框架中学到的一件事是，要在不同语言之间复制这一点也是非常困难的。有了GRPC，我们确实找到了一个令人愉快的中间说法，有一个内置的服务框架可以用来用GO优雅地编写代码，但GRPC允许我们缩小外围应用的范围，并提供可以支持不同开发模型的强类型客户端，这种模型可能有更大的空间来推动微服务以框架无法实现的方式广泛采用。

此外，我们还包括GRPC-web生成的客户端，使前端能够快速、轻松地利用类型化的Javascript客户端来利用与后端相同的开发。我们已经看到GRPC-web在不同的公司内部慢慢被采用，并认为这可能也会相当快地扩展到公共领域。

有关生成的客户端，请参见Micro/Client/SDK目录。这些将在不久的将来被公布给各自的套餐经理。

Micro的目的是让微服务开发变得容易得多，并提高后台开发人员的生产力，除了能够使用GRPC消费这些服务之外，我们认为世界仍然真正关心基于HTTP/JSON的API，因此Micro包括一个API网关，它可以自动将http/json转换为GRPC请求。这意味着每个人都不需要做任何事情就可以在云中构建API First服务。

语法="；Proto3"；；Package HelloWorld；service HelloWorld{RPC Message(Request)Returns(Response){}}Message Request{String name=1；}Message Response{String msg=1；}。

那就把这件事曝光。

.