Asim Aslam谈Micro：Go微服务工具包

我是阿西姆·阿斯兰，欢迎收听Go Time。

I'm Asim Aslan, and this is Go Time.

Go Time是一档每周播出的播客，我们将讨论围绕Go编程语言、社区以及其间所有话题的有趣内容。

It's Go Time, a weekly podcast where we discuss interesting topics around the Go programming language, the community, and everything in between.

如果你目前正在使用Go，或者希望学习Go，那么这档节目非常适合你。

If you currently write Go or aspire to, this is the show for you.

好了，各位。

Alright, everybody.

欢迎各位再次收听Go Time的另一期节目。

Welcome back for another episode of Go Time.

这是第八期节目。

This is episode number eight.

今天我们有一位特别嘉宾阿西姆·阿斯兰，他将和我们讨论这个框架。

We have a special guest with us today, Asim Aslam, and he's going to talk to us about the framework.

我们还一如既往地连线了布莱恩·凯特尔森。

And we also have Brian Kettleson on the line, as always.

你好。

Hello.

我们还有精彩的卡尔丽萨·卡马斯也在连线中。

And then we have the wonderful Carlissa Campos also on the line.

很高兴能来这里。

Glad to be here.

你好。

Hello.

让我们大家给奥斯汀热烈的欢迎。

And let's give everybody have everybody give Austin a warm welcome.

如果你愿意，可以先做个简短的自我介绍，讲讲你的背景，然后我们再进入微框架的话题。

And if you could, go ahead and give us a brief introduction, a little bit of history about yourself, and then we'll kind of roll into the whole micro framework.

当然。

Sure.

谢谢你们邀请我参加这个节目。

So thanks for having me on the show.

我非常感激。

I really appreciate it.

我的背景是，过去十年左右我在伦敦从事各种系统管理员和SRE工程相关的工作。

Basically, my background is I've spent the last kind of ten years in London doing various kind of sysadmin, SRE engineering kind of roles.

我曾在一家初创公司工作，后来这家公司被谷歌收购，我在谷歌待了一段时间，学习了如何构建大规模系统，从内部见证这一切非常令人兴奋。

Worked at a startup, which later got acquired by Google, spent a bit of time at Google learning how to build systems at scale, which was really exciting to see from the inside.

那时谷歌云还处于测试阶段。

This was when Google Cloud was still actually in beta.

然后我在Halo工作，于2013年帮助构建了一个全球微服务平台。

And then I went to work at Halo and help build a global microservices platform back in 2013.

那时候，这根本还不是什么热门话题。

When, you know, it wasn't really much of a thing.

当时只有Netflix在谈论这个概念。

Think Netflix was the only one talking about it.

现在我正在从事一个叫作micro的项目。

And now I'm working on this thing called micro.

你知道吗，我意识到各家公司内部其实都在做着相同的事情。

You know, I realized everyone was really doing the same thing internally at companies.

而且，如果有一个社区项目能做同样的事，让我们都能参与贡献、学习和从中受益，那就太好了。

And, you know, it would be nice if there was a community project that was doing the same where we could all contribute and kind of learn and benefit from it.

基本上，就是做这件事：简化分布式系统的构建与管理。

And basically do this thing of, you know, simplifying, building and managing distributed systems.

而目前我就在做这个，正在构建它，希望有人愿意使用它。

And, you know, that's really where I am at the moment, just kind of building that and hoping people will want to use it.

所以当我第一次看到 Micro 时，我觉得最让我印象深刻的是——那是二月，已经过去很久了。

So when I first saw Micro, I think the thing that impressed me most, and this was February, it's been quite a while.

但最让我印象深刻的是，你所做的设计决策似乎抓住了完成工作所需的一切关键要素。

But the thing that impressed me most was, the design decisions that you've made seem to be, what's the word I'm trying to think of, it encapsulates almost everything you need to get the job done.

它更像是一个完整的框架，而不仅仅是一个工具包；用 Go 术语来说，Gorilla 工具包是一堆你可以用来构建网站的组件。

And it's more of a full framework than a toolkit And to use frequent go terminology, whereas the Gorilla Toolkit is a bunch of things you can use to build websites.

但 Micro 相对来说是高度自包含的。

But micro is pretty relatively self contained.

我真的很喜欢这一点。

And I really enjoy that.

我认为在微服务中拥有这样一个立场鲜明的框架很不错。

I think it's nice to have a strongly opinionated framework like that in the microservices.

谢谢。

Thanks.

我的意思是，措辞总是很难把握。

I mean, I guess the wording is always hard.

你知道，你可以反复斟酌它应该是什么样子。

Know, you can kind of go back and forth on what it should be.

但你知道，从在公司内部构建东西的经验来看，一个库是不够的，一个工具包也是不够的。

But, you know, learning from the experiences of building something within a company, a library does not suffice, a toolkit does not suffice.

我们本质上为公司构建了一个平台即服务或微服务平台即服务。

We essentially built platform as a service or microservices platform as a service for the company.

这意味着为开发者——我们的客户——提供一切，让他们能够专注于自己需要专注的事情。

That meant providing everything to the developers who are our customers and letting them kind of focus on what they need to focus on.

所以当我构建这个时，我认真思考了什么是基本的构建模块？

So when I built this, I really thought about what are the fundamental building blocks?

如果你先以开源的方式构建，你会怎么做？

How would you do it if you built it open source first?

所以它必须是可插拔的。

So it needs to be pluggable.

而且，它慢慢演变成了现在这样。

And, you know, it slowly evolved.

我的意思是，它最初只是 go micro，那个核心项目。

I mean, started as just go micro, the kind of core project.

而现在它变成了一个更大的东西。

And now it's this bigger thing.

我现在称之为一个生态系统，试图进一步扩展它，满足每一个需求。

And I'm kind of, I'm calling it an ecosystem and trying to build it really further out and address every requirement.

但同时也想说，看，它是可插拔的，我们把复杂的事情交给那些专注于这些事情的人和工具。

But also kind of saying, look, it's pluggable, we offload the hard things to, you know, to the people and the tools that are really focused on those things.

所以服务发现有一个对应的接口。

So service discovery, there's an interface for it.

但如果你想要一个一致且分布式的解决方案，你可以使用 Consul、etcd 或其他类似工具。

But if you want something that is consistent and distributed, you know, you can use console or etcd or anything like that.

对于其中的其他所有包也是如此。

It's the same for all the other kind of packages within there.

之前

Before

在我们深入讨论 micro 之前，Sam，看起来你一直在专注于 micro。

we geek out on micro, Sam, it seems that you're working exclusively on micro.

这是真的吗？

Is that true?

如果是的话，这个项目以及你个人的财务可持续性计划是什么？

And if so, what is the financial sustainability plan for the project and for yourself?

当然。

Sure.

没错。

So, that's right.

我全职做这个。

I'm working on it full time.

我大概一年前辞去了在Halo的工作，因为我对这个项目非常有信心，想把它做出来。

I basically I quit my job at Halo over a year ago, because I felt so strongly about this and I wanted to build this.

当时的想法是，去和一些风险投资人谈谈。

And at the time, had the plan was, was talking to some venture capitalists.

计划是：我要筹集资金，组建团队，然后按照硅谷的方式去干。

The plan was, hey, I'm going to raise this money, build this team, and we're going to go off and do this, you know, the Silicon Valley way.

但实际上，我们在伦敦，所以没办法那样做。

And actually, were, you know, we were in London, so no, we couldn't do it that way.

最后，我只好独自一人干。

And I ended up kind of going it alone.

幸运的是，我有些积蓄，所以能继续坚持下去。

And luckily, had some savings, so I kept going.

后来，我一位朋友，他以前在Halo工作，现在去了第六租车公司，去那里搭建平台时看到了我在做的事，我们于是达成了一项协议。

And eventually, a friend of mine who, you know, a friend of mine who was at Halo, who's now at sixth, the car rental company, he went there to build a platform and he saw what I was doing and, and we kind of, you know, worked out a deal.

这家公司实际上在资助这个项目，让我能继续全职投入，这真是太好了。

And, there that company is essentially sponsoring the project so that I can continue to work on this full time, which is really great.

太酷了。

Very cool.

是啊。

Yeah.

我总是很喜欢听到这样的项目：人们能被赞助全职做自己热爱的事，因为我知道很多人对开源项目充满热情。

I always love to hear projects that work that way where people get sponsored to work on them full time because I know a lot of people get really passionate about their open source projects.

但很多时候，当他们换到新公司，不再获得支持时，这些项目就变成了废弃软件。

And a lot of times they become abandonware when they move on to new places that no longer sponsor.

这真的很难。

It's really tough.

我觉得自己非常幸运，因为这位我曾密切合作的朋友去了这家大型企业，他能看清其中的价值，完全理解我的计划，并愿意以这种方式帮助我。

I think I got very, very lucky in the sense that, you know, this friend of mine who I'd worked with closely was going to this large enterprise company and, you know, he could see the value and he knew exactly what I was planning to do and was willing to kind of help out in that way.

许多构建开源项目的人，尤其是那些大型开源项目，并没有获得同样的好处。

Many people who build open source projects, very, very large open source projects don't get that same benefit.

看到这种情况真的很难受。

And it's really tough to see that.

我知道有很多人正在努力解决这个问题，但我们也必须在这方面做得更好。

And I know that there's a lot of people kind of working on ways to fix that, but we definitely need to do better work there as well.

那么我们来谈谈采用情况。

So let's talk about, adoption.

你对使用 Micro 部署服务的公司数量或规模有什么了解吗？

Do you have any sense of the, the numbers or scale of companies that have deployed services with Micro?

我设置了一个用户页面，上面列出了大约四家公司，其中有几家已经上线生产。

So there's I set up a users page, there's about four companies listed there, a couple of which have gone to production.

你可以在主仓库的维基页面上找到这些信息。

You can find that in the main repository in the wiki.

还有大约五到六家公司完成了调查，表示他们在未来三到四个月内将进入生产阶段，但我仍在跟进他们，看他们是否愿意公开自己的名称等信息。

There's maybe about five or six other companies who did a survey and said they would be on the way to production in the next three or four months, but I'm still chasing them up to see if they want to publicly name themselves and whatnot.

所以增长是缓慢而稳健的。

So the growth is slow and nice.

有趣的是，有一个Slack群组，所有人都加入其中，新的公司或个人会来分享他们的使用经验，而人们在使用它时甚至都不需要我知情。

Think the nice thing is there's this Slack where everyone joins and new companies or individuals from companies come along and, kind of talk about their uses and people are using it without me even knowing.

不知为何，它在中国发展得特别快，这真的非常令人欣慰。

For some reason, it's really taking off, in China, which is really, really nice to see.

有人甚至把整个博客翻译成了中文，这真的很酷。

And someone even translated the entire blog into into Chinese, which is really cool.

在这里，伦敦，我刚会见了一家叫Kazzoop的公司。

And, here in London, I just met with a company called Kazzoop.

他们基本上发布了第一个包含Micro的职位招聘信息。

And they, have essentially, you know, they've posted the first job listing, including micro.

对我来说，这非常有意义，有人如此重视它，以至于愿意把它写进招聘启事，说：‘我们正在转向这个框架。’

And that's, you know, for me, that's really profound that someone thinks so much of it, they want to put it in a job listing and kind of say, Hey, we're, we're moving over to this framework.

而且还会注明我们愿意为做这件事的人支付多少薪酬。

And here's what we're going to pay for someone to do it.

这真的很酷。

So that's pretty cool.

他们是在找有十年经验的开发者吗？

Are they looking for a developer with ten years of experience?

不，他们想找的是懂Go语言、想构建微服务并能做这类事情的人。

No, they're looking for someone who knows Go and wants to build microservices and can kind of do this stuff.

我觉得微服务最棒的地方在于，这些服务的代码量可能不到一千行。

Think the awesome thing about microservices in general is really you know, these things are maybe less than a thousand lines of code.

你所构建的东西是非常领域特定的。

It's very domain specific what you're building.

因此，构建这些东西并不像你想象的那样需要那么多东西，这意味着拥有六个月或一年经验的人完全可以胜任，刚接触Go语言的学习者也可能做到，因为归根结底真正重要的是API，也就是你与该应用程序交互的接口，代码本身并不重要，因为未来你随时可以重写它。

So it doesn't require as much as you think to kind of build that stuff, which means people with, you know, six months experience, a year's experience could really do this stuff, help people learning go for the first time could probably do this, because what really matters is the API at the end of the day, the you know, the interface to that application that you're communicating with, code is irrelevant because you could rewrite that anytime in the future.

这引出一个有趣的问题。

Well, brings up an interesting question.

从哲学上讲，你觉得微服务和比微服务更大的系统之间的分界点在哪里？

What do you feel philosophically is the delineation point between a microservice and something that's bigger than a microservice?

这很难说。

That's a tough one.

对我来说，我发现，只要我能轻松地记在脑子里，感觉还比较简单，那就是了。

For me, what I've found is, it's whatever I can kind of keep in my head and still feels fairly simple.

在过去三四年里，我写了大量Go代码，还实际构建过一个微服务平台，我认为对于Go来说，很多时候它确实会落在1000到2000行代码的范围内，你知道，每种语言都有不同的语法，因此最终会对应到一定的行数。

And having written a lot of Go in the last three or four years and actually having built a microservices platform, I'd say a lot of the time it does fall into a 1,000 to 2,000 lines of code thing for Go specifically, you know, every language has a has a different kind of, syntax, therefore it's going to, you know, come down to a certain number of lines.

对于Go来说，它就是自然地感觉像这样。

For Go, it just, you know, it feels naturally like that.

但很多时候，你其实心里有数，因为这是一种理念，你一看代码就知道，如果做一件事要花超过一周时间，那它可能就太大了。

But it's, you kind of, you kind of know a lot of the time, because this is a philosophy, you just know from looking at the code, if it takes longer than a week to do something, then you know, it's probably too big.

如果你在修改某个东西时，需要花很多精力去构建这个心理模型，那你也知道它太大了。

And if, you know, it takes you a lot of work to build that mental model as you're trying to change something, then you also know it's too big.

这是一个有趣的衡量标准。

That's an interesting measure.

因为我在想，当你刚开始设计某个东西时，也许你指的就是设计阶段、创建阶段，你能把多少东西记在脑子里。

Because I think, I'm thinking at the beginning when you're designing something, and maybe that's what you mean, like at design time, at the creation time, how much you can hold it in your head.

因为对我来说，随着时间推移，我越来越熟悉一个代码库——比如我连续两年都在维护这个代码库，我能记住的东西远比前两个月多得多。

Because for me, as time goes by, more and more, and I'm working with a code base, I mean, two years that I work with a code base, I can hold a ton more than what I could in the first two months.

是的，这确实是个有趣的观点，我认为你说得对，时间越长，你就越能记住更多内容，并在脑海中构建出模型。

Yeah, it's an interesting one of, I think, I mean, I agree in that the longer you go, the more you can kind of remember about it and kind of model in your head.

但与此同时，如果你暂时离开项目，再回来时，需要多长时间才能重新构建起这个模型呢？

But at the same time, if you leave the project for a little while and come back, how long does it take you to kind of build that model again?

对我来说，关键在于我是否能将整个模型都保留在脑海中。

For me, it's the case of, kind of, can I hold the entire model in my head?

我能否非常轻松地在脑海中修改这个模型，然后迅速地将其转化为代码？

Can I make changes to that model in my head in a very, very easy manner, and then put it down in code very, very quickly?

很多时候，我确实可以，你通常能大致感觉到什么时候它行不通。

A lot of the time, I can, you know, you can kind of generally get a feel for when it's not working.

我认为，从MVC背景过来的人，比如熟悉Rails之类的人，会习惯这种模块化结构。

I think people coming from an MVC background, you know, rails and whatnot, you get used to the modularity.

所以你会遇到百万行代码的代码库，但你依然能找到方法在模块化的空间里编写代码。

So you'd have code bases that are a million lines code, and you'd somehow figure out how to code in the modular space.

但在微服务世界中，我认为你必须完全掌握服务本身的全部范围。

But in the microservices world, I just think you kind of need to have full scope of the service itself.

很多时候，我们在一两天内就快速开发出服务并将其部署到生产环境，至少我在Halo工作时是这样。

And a lot of the time, you know, we're hacking out services in the space of one or two days and shipping them to production, at least when I was at Halo.

我认为这没有对错之分，对每个人来说，情况都不同。

And, I would say there's no right or wrong, you know, I think for everyone, it's a different thing.

你真的得选择适合自己的方式。

And you kind of, you really have to go with what works for you.

我喜欢这种理念，因为它非常注重权衡。

And that's what I like about the philosophy because it's a lot about trade offs.

所以，当一个团队聚在一起时，他们会逐渐找到适合彼此的工作方式，以及适合他们的服务数量和代码库规模。

So, you know, I think when a team comes together, there's certain, you know, they kind of figure how they all work and what number of services work for them and what code bases, sizes of code bases work for them.

我同意。

I agree.

我觉得你说得非常对。

I think you have a very good point.

我喜欢这种思维方式。

I like that way of thinking.

你可能不会在整个团队中完全采用这种方式，这取决于你的团队构成，但你绝对可以把它作为一种补充。

You might not even use exclusively on a team depending on how your team is made up, but you can definitely use it as a compliment.

是的，对我来说，我现在更关心的问题是，我们已经看到这些现象在组织中上演。

Yeah, I think for me now that the question I'm thinking more about is, you know, we've seen all this kind of stuff play out in organizations.

我想看看它在开放开发者世界中是如何运作的。

What I want to see is how this works in the open developer world.

如果我们作为普通开发者协作构建整个产品，使用微服务，这可行吗？我们能在多大程度上实现这一点？

If we were to collaboratively build entire products with microservices just as general developers, would that work and at what scale could we actually achieve that?

这是一个有趣的概念。

That's an interesting concept.

我从未想过微服务可以存在于企业之外的场景。

I hadn't thought of microservices outside of something that looks like an enterprise.

这正是我整个微服务理念的真正方向。

That's where I'm really going with this whole micro thing.

我长期从事组织方面的工作。

I've done the organization thing for a long time.

我认为我所开发的工具对组织会有用，但同时，我更感兴趣的是我们开发者群体能共同做些什么。

I think the tools that I build will be relevant to organizations, but at the same time, I'm more interested in what we can collaboratively do as a developer community.

你知道，GitHub 就是我们共同协作开发库和其他类似项目的绝佳例子。

You know, GitHub is a great example of us collaborating on libraries and things like that.

但如果我们协作开发微服务呢？

But what if we collaborate on microservices?

比如，一个人或两个人编写一个微服务，然后另一个人使用它的 API，接着又有人构建另一个微服务，我们就这样持续下去。

So a person, two people write a microservice, then someone else consumes the API, then someone else builds another one and we kind of keep going like that.

我们到底能构建出什么？

What could we actually build?

如果我们这样做，就能停止重复构建过去那些老东西，转而开始构建全新的东西，对吧？

And if we do that, then we stop rebuilding the things that we used to build and we can start building new things, right?

这样，我们就彻底推动了软件开发的进步。

So we kind of shift software development forward entirely.

我觉得这对我来说非常吸引人。

And I think that's really intriguing to me.

所以我认为，你想象的更像是Linux的生态，对吧？

So I think, so you're imagining this more like the Linux landscape, right?

那里有很多小型工具，可以轻松组合在一起。

Where there's lots of small tools that can be combined easily.

没有人会每次都重新编写这些组件，对吧？

Nobody kind of rewrites each of those pieces every time, right?

他们只是——

They just-

没错，正是如此。

Yeah, exactly.

上一次有人重写grep、ls或cat之类的东西是什么时候？

Like when's the last time someone rewrote grep or LS or cat or something like that.

一旦它们被构建出来，就永远定型了。

It's like once they're built, they're built.

不，我觉得这个想法很有趣，但从运维的角度来看，这会是什么样子呢？

No, I think that's an interesting thought, but how does that look from, kind of the operations perspective?

那么，谁来负责所有这些组件呢？

Like, who's responsible for all of those?

这些是运行在某个地方、你可以直接使用的微服务，还是你需要下载这些版本并安装到自己系统里的微服务？它们具体是怎么运作的？

Are these microservices that are running out somewhere that you you leverage or are these microservices that you're downloading these versions of and installing How's within your own that look?

所以，假设我们所有参加通话的人正在共同合作某个项目。

So think, so say all of us here on the call, we were all collaborating on some project.

如果我们是在做一个个人项目，很多时候人们会去找个托管服务，然后在那里运行一些东西。

Now, how would we do it, If we're building a side project, a lot of the time people will go find some hosting and start running some stuff there.

但如果我们能把各自不同的 DigitalOcean 资源串联起来，构建一个网络，然后集体在里面运行微服务，会怎么样呢？

But what if we kind of, what if we could string together our disparate digital ocean kind of resources, create a network and then run microservices in there collectively?

这正是我真正想的。

That's what I'm really thinking.

我认为这应该是实际为网络做贡献的人们共同承担的责任。

I think it'd be kind of a shared responsibility between the people actually contributing to the network itself.

我长期以来一直在构建平台即服务，我认为自动化在这方面起着关键作用。

Then I've built platform as a service for a very long time, I think the part of automation really plays in.

你必须构建自愈的自动化系统，能够应对这类故障。

You have to build you know, self healing, automated systems that can kind of deal with this sort of failure.

我的意思是，我们讨论的是分布式系统，对吧？

I mean, we're talking about distributed systems, right?

所以它们必须具备容错性。

So they have to be fault tolerant.

我认为这与此密切相关，当你启动平台后，所有东西都以服务的形式编写，甚至管理基础设施的服务也是微服务，这非常有趣。

So I think that kind of plays into it and it's really fun and kind of interesting when you get to a point where you bootstrap the platform and then everything is written as a service and even services that manage the kind of the infrastructure are microservices.

所以我认为，你可以达到这样一个状态：没有任何个人，没有任何真实的人在管理其中任何一部分。

So I think you can kind of get to a place where no individual, no actual human being is managing any of it.

它实际上是完全自动化的。

It's actually completely automated.

你有着宏大的梦想。

You've got big dreams.

我有非常远大的梦想，但我也拥有实现它们的时间。

I have very big dreams, but I also have, you know, the time to do it.

这就是时间的奢侈。

And that's the luxury of time.

所以这相当不错。

So that's quite nice.

从技术角度来看，我欣赏微框架的一点是，你可以通过多种不同的媒介与框架交互。

So from a technical perspective, one of the things I appreciate about the micro framework, is that you can interact with the framework from multiple different media.

例如，命令行工具、机器人和API本身。

For example, the command line tool, the bot, the API itself.

设计这样的系统时，背后有哪些考虑？

Designing that, what went into that?

你们是如何设计服务的，才能让它们如此容易地通过多种不同媒介进行交互？

How did you design the services in a way that made it really easy to interact from so many different media?

所以我在这一点上有点取巧了，你知道，在Halo，我们已经有了很多这些东西。

So I sort of cheated a little in that, you know, at Halo, we had a lot of these things.

你知道，我们有一个将HTTP转换为RPC的API。

You know, we had the API that would convert HTTP to RPC.

我们还有作为微服务的Web应用程序。

We we had, you know, web applications as microservices.

我们在HipChat中使用了Hubot，这正是我萌生机器人想法的地方。

We had Hubot in HipChat, which is where I kind of got the idea for the bot.

此外，我们还有一个shell或命令行界面。

And then we also had a shell or a CLI.

于是我将所有这些想法整合在一起。

And so I just took all those ideas in it.

我知道，当你在构建这些东西时，必须能够与之交互。

And I kind of knew that, you know, when you're building this stuff, you need to be able to interact with it.

你还需要从遗留系统的角度能够与之交互。

And you also need to be able to interact with it from a legacy standpoint.

从可用性的角度来看，如果我有一个命令行界面，就能轻松查看情况并查询信息。

And just a usability standpoint of, Hey, if I have a CLI, it's really easy for me to see what's going on and query things.

如果我有一个提供HTTP服务的API，那么通过浏览器、curl或其他任何工具与这些服务交互就会变得非常简单。

If I have an API that serves HTTP, it makes it very simple to talk to these things via a browser or curl or anything else.

当你提供面向公众的API时，显然每个人都希望使用REST或未来类似的协议。

When you're serving public facing APIs, obviously everyone wants rest or something similar in the future.

我认为一切都应该转向RPC。

Think I want everything to move to RPC.

我认为这也是gRPC真正的愿景。

And I think that's the really the dream of gRPC as well.

我认为他们谈论的是移动优先并这样做，但这一切并没有同时发生。

I think they're talking about mobile first and doing that, but it was just that it didn't all happen at once either.

要知道，它始于命令行，然后是API，接着是Web界面，如此类推。

Know, it started with the command line, then it was the API, then it was the web UI and so on and so forth.

在进行这类开发时，这一点是需要记住的，对吧？

And that's the thing to remember with any of any of this kind of development, right?

这是一个缓慢而渐进的过程。

It's a slow kind of progressive thing.

你不可能一开始就弄清楚所有事情，但这也是一种分层架构，因为你最初只构建所需的核心功能。

You're not going to have everything figured out, but it's also a layered architecture in the sense that you build exactly what you need at first.

然后不要混淆这个核心部分，而是在其周围构建，并持续在其周围和之上不断扩展。

Then rather than conflating that core thing, build around it and continue to build around it and on top of it.

现在我们稍微回退一下，谈谈这个框架到底是什么，我觉得我们还没真正梳理过这个框架的功能，比如它为你抽象了哪些东西。

And now backing up a little about what the framework actually is, I don't think we've actually kind of stepped through kind of what the framework does, like what it's abstracting from you.

我们之前谈到了可插拔组件，但或许我们应该花点时间说明一下这些组件具体是什么，尤其是对那些可能不熟悉分布式系统各个部分的人。

Kind of we talked about pluggable components, but we we should probably take a second to talk about what those pieces are, especially for people who might not be familiar with kind of all the pieces of of of part of a distributed system.

当然。

Sure.

这是个很好的观点。

So that's a good point.

谢谢你提出这一点。

Thanks for raising that.

所以我先从 micro 开始，它首先是一个工具包，旨在让构建和管理微服务变得更加容易。

So I'll start with micro, the kind of first thing, it's a toolkit that kind of makes it easier to build and manage microservices.

核心是一个名为 GoMicro 的库，这是一个可插拔的 RPC 框架。

At the core, there's this library called GoMicro, which is a pluggable RPC framework.

这个核心库为你构建微服务提供了基本功能。

And the idea is that that core library provides you the fundamentals for building microservices.

当你想到微服务时，它是一种面向服务的架构。

So when you think about microservices, it's this, you know, service oriented architecture kind of thing.

你会想，那里需要什么？

You think, what do I need there?

需要某种通信方式。

Need some sort of communication.

我需要消息编码。

I need message encoding.

通信可能是同步的，也可能是异步的。

Communication might actually be synchronous and asynchronous.

我需要能够处理请求。

I need to be able to serve requests.

我需要能够发出请求。

I need to be able to make requests.

这些核心功能都得到了解决，除此之外没有别的。

So those things are really addressed at the core and nothing else.

它只关注这些基本需求，因为其他你可能想到的东西，比如监控、分布式追踪等，其实并不一定是在构建微服务时必需的。

It only addresses those fundamentals because the other things that you think about off monitoring, distribute tracing and things like those, you don't necessarily need those to just build microservices.

因此，这门课程的重点就是帮助你构建微服务。

So that was really the focus of the course of helping you build microservices.

然后，正如布莱恩提到的，工具包的外层是入口点。

Then the kind of outer layer of the toolkit, as Brian mentioned, is the entry points.

有一个命令行界面、一个API、一个网页界面，还有一个提供HTTP接口的边车，它具备Go Micro的所有功能。

There's a CLI, an API, there's a web UI, there's sidecar that provides a HTTP interface that has all the features of Go Micro.

所以，如果你不想用Go语言编写，而是想用Python、Ruby、JavaScript等语言，你只需通过HTTP接口与之交互，就可以这样使用。

So if you want to write stuff not in Go, like if you want to write in Python, Ruby, JavaScript, whatever, you can just interact with the HTTP interface and kind of use it that way.

这类似于Netflix的边车工具，他们称之为Prana。

It's similar to Netflix has something called Prana, which is their sidecar.

Buoyant 有一个名为 Linkerd 的工具。

Buoyant has something called Linkerd.

所以这些都相当突出。

So these are kind of prominent.

但没错，核心理念其实是为你提供编写微服务所需的基本要素。

But yeah, the idea is really, you know, providing you the fundamentals for actually writing microservices.

我认为许多人目前正专注于这一运行时层面。

I think many people are currently addressing that kind of runtime aspect.

他们说，这是如何运行微服务的。

They're saying, here's how you run microservices.

这是基础设施方面你需要的工具。

Here's the tools that you need in the infrastructure side.

但我认为人们仍然在苦苦思索：我究竟该如何编写微服务？

But I think people are still really struggling with, well, how do I actually write microservices?

比如，有哪些工具支持这一点？

Like where are the tools for those?

我认为目前在这方面真正可用的工具非常少。

And I think there's very few tools actually around for that.

我知道Netflix有一套非常优秀的Java工具来实现这一点，但我们在Go语言中却缺少这样的工具。

I know Netflix has a very, very good suite of tools to do it in Java, but we were sort of missing these tools in Go.

要感谢彼得·博根，他一年前或更早就开始开发GoKit了。

And, credit to Peter Borgen who, you know, a year, or more ago, started work on GoKit.

大约在同一时间，我也开始开发Go Micro。

And around the same time, I I started work on, Go Micro as well.

因此，现在开始出现一些有助于解决这个问题的工具。

And so there's some tools now kind of surfacing to help with this.

但我觉得我们目前主要关注的是开发层面，而其他大公司则更关注如何运行这些服务。

But I think we're really focusing on the development side and companies at large at the moment are, other companies are focusing on how do we run them.

好的，这实际上引出了一个很有价值的问题，我们Slack频道里有一些人也在问同样的问题。

Okay, so that actually brings up a valid point, and we have some people in the Slack channel who are kind of asking the same thing.

你会如何比较和对比Micro和GoKit呢？

How would you compare and contrast kind of micro versus GoKit?

比如，你觉得它们的目标人群是一样的吗？

Like, do you see them targeting different groups of people the same?

我认为，总的来说，整个社区是一样的，对吧？

I think, you know, I think the community at large is the same, right?

那些想要用 Go 写东西的人。

People who want to write stuff with Go.

但与此同时，这也关乎你偏爱哪种方式来构建应用程序。

But at the same time, it's the thing of like, you have a preference to the way in which you're going to build applications.

所以每个人都会去看各种库和服务，然后想：我喜欢这个，或者我不喜欢这个。

So everyone's going to kind of look at libraries and services and things and go, I like this or I don't like this.

就像以前该选 MySQL 还是 Postgres 一样，现在也是同样的问题：该选这个库还是那个库？

So in the days of like, should I pick MySQL or Postgres, it's the same kind of thing of like, should I pick this library or that one?

据我所见，GoKit 的标语是面向微服务或分布式系统的标准库。

And I think GoKit is, from what I see the tagline, it's a standard library for microservices or distribute systems.

它正在解决许多非常扎实的问题，并且目前有大量开源贡献。

And it's addressing quite a lot of very, very solid things and has huge kind of OSS contributions going on at the moment.

所以这真的很棒。

So that's really, great.

从微观层面来看，它解决的同样是那些基础问题，但对我来说，我是基于自己的经验来构建的。

From the micro side, you know, it's addressing the same kind of things, the fundamentals, but for me, I'm building based on my experiences.

我构建了我在生态系统中没怎么看到的工具。

I'm building the tools that I didn't really see in the ecosystem.

我喜欢非常简洁的接口。

And I I like very simple, interfaces.

我喜欢低门槛。

I like a low barrier to entry.

当我实际编写服务时，我不想关心细节，我希望尽量少的样板代码。

I don't want to care about the details when I'm actually writing services, I want very little boilerplate.

我需要我所需的所有工具，当我开发微服务时，我希望一切都能齐全。

And I need the entire toolkit I need like, I need, I want everything, you know, when it comes to right running, writing microservices.

所以我认为它们略有不同，你必须自己去审视它们，看看它们对你有什么好处，因为确实有很多人使用GoKit，他们非常喜欢它，喜欢那些抽象层。

And so I think they kind of differ a little bit and you have to, you know, I think everyone has to look at them themselves and kind of see where the benefits are for them because there are lots of people using GoKit, you know, they really like it, they like those abstractions.

这确实是一件很棒的事。

And that is, a really great thing.

选择非常重要。

Think choice is very, very important.

是的，我觉得你提出了一个很有道理的观点。

Yeah, and I think you bring up a valid point too.

布赖恩和我在之前的一家雇主公司有过类似的经历，那就是我们实际相识的地方。

Brian and I had kind of a similar situation at a prior employer that both of us worked at, the one we actually met at.

有很多人热衷于构建这些分布式框架，实现通信、容错和服务发现。

So you have a lot of people who are interested in building these distributed frameworks and making the communication happen and making things fault tolerant and service discovery.

而另一些人则只是专注于业务相关的功能。

And then you have a lot of people who just work on business related features.

所以根据我对这两个项目的理解，你的项目似乎更侧重于让开发者只需编写服务，而无需操心让服务之间相互通信的所有细节，从而能够专注于业务逻辑。

So at least from my understanding of the two projects, it seems like yours more targets being able to just write the service and not have to think about all the bits that make the services communicate between each other and allow you to just kind of focus on the business logic.

你说得非常准确。

I mean, you're dead on.

你说得对。

You're dead on.

这正是我们在Halo构建平台时的核心理念，当时每个人都会提到，整个平台团队以及构建这个系统的人的目标是：我们不希望任何人去思考分布式系统。

This was the really, when we built the platform at Halo, the, the thing that everyone would say, and the goal from the entire kind of platform team and those who are building this thing was, we don't want anyone to have to think about distributed systems.

我们希望他们能够利用这些系统。

We want them to be able to leverage them.

但你知道，我们毕竟在经营一家公司，对吧？

But you know, everyone is, I mean, we're building a business, right?

我们需要为业务开发服务，而并不真正关心那些其他的技术细节。

And we need to write services for the business and we don't really care about that kind of other stuff.

在这里，微服务的目标也是如此。

And in the same way here, micro, that's the goal.

就像，我不想操心所有那些细节。

Like, you know, I don't, I don't want to have to care about all those details.

我为什么要去操心呢？我只想写软件。

Why should I, like, I just want to write software.

我想构建我的服务。

I want to build my services.

即使如此，当我构建这些东西时，我会想，也许这些内容中的一些东西太底层了。

And even then, like, I think about, you know, as I'm building this stuff, I'm thinking about like, maybe even these things, some of these things are too low level.

也许我们需要找到一种更上层的方法。

Like maybe we need to find a way to go higher up.

我认为随着时间的推移，我们会做到的；目前的情况是，当你编写微服务代码时，你最终会关注于：我要调用这个服务，调用那个服务，获取这些数据，进行转换，然后返回。

I think, over time we will, you know, I think at the moment is the thing of, you know, when you're writing code, microservices code, you end up kind of focusing on, well, I'm going to call this service and I'm going to call this service and I'm going to take this data and I'm going to transform it and return it.

到了某个阶段，你会意识到，我真正关心的是信息本身。

And at a certain point you think, well, what I really care about is like the information.

我并不真的在意它在哪里，但我需要的是：嘿，给我这个用户的全部地理位置信息。

I don't really care where it is, but I need, it's kind of like, hey, give me all the geolocation information for this user.

我不关心这些信息分布在多少个不同的服务里，只要把它们给我就行。

I don't care how many different services it's in, just give it to me.

然后我会把这些信息收集起来，进行转换，再返回给用户。

And then I'll gather this and I'll transform it and pass it back to the user.

这有点像，如果你想想杰夫·迪恩和桑贾伊·格玛瓦特在谷歌早期开发MapReduce时的做法，对吧？

It's kind of, if you think about what Jeff Dean and Sanjay Gammawat did with kind of MapReduce at Google in the early days, right?

本质上是一样的。

It's the same thing.

就是减少你获取真正关心的数据所需做的工作量。

It's like reducing the amount of work you have to do to get that data you really care about.

所以我认为这就是我们未来的方向。

So I think that's where we're going.

是的。

Yeah.

我看过几次文档。

I've looked through the docs a couple of times.

不幸的是，我还没实际用微服务做过项目，但我觉得它似乎相当包容。

Unfortunately, I haven't actually built anything with micro, but I mean, seemed pretty inclusive.

我喜欢这样的理念：你可以替换你的消息代理，也可以替换你的服务发现机制。

Like I liked the idea that you could change out your messaging brokers, you could change out your service discovery mechanisms.

这些都是痛点。

And these are all pain points.

我们许多构建分布式系统的人，都经历过这样的困扰：比如，我喜欢Zookeeper做这件事，但对另一件事却很讨厌。

Many of us who have built distributed systems have suffered through, like, oh, well, I like Zookeeper for this, but hate it for something else.

你会经历一系列迭代，不断更换组件，而能够轻松替换这些组件并尝试不同方案，确实很好。

And you kind of go through these iterations where you switch out, And it it's nice to just be able to swap those components out and try different things.

而且，你知道，你的团队里可能有人擅长支持ActiveMQ之类的，而不是ZeroMQ之类的工具。

And, you know, maybe maybe people on your team know how to support, you know, ActiveMQ or something versus ZeroMQ and things like that.

是的，我觉得这正是关键所在。

Yeah, I think that was totally the point.

我想第一个原因是，我们在Halo开发这些内容时，因为赶工期，把所有东西都内置进去了。

I think the first reason was when we built the stuff at Halo, we kind of baked everything in because we're on a deadline.

当我们考虑开源时，才发现所有东西都被硬编码了，很难剥离出来，而且任何本地开发都需要运行十个不同的服务及其所有依赖才能正常工作。

And then when we thought about open sourcing it, we realized that everything is, you know, kind of hard coded in a way that it makes it difficult to strip it all out and, and doing any kind of local development meant you had to run 10 different things and all their dependencies to make it work.

我们想开始构建这些东西。

Want to start to build this stuff.

我知道，我希望它能够插件化。

I knew that, you know, I want it to be pluggable.

我希望尽量减少启动所需的依赖项数量。

I want it, to minimize the number of dependencies that you needed to get started.

说到你的观点，每个人都有不同的技能。

And on your point, you know, everyone has different skills.

每个人喜欢不同的工具，我认为在同时保持相同的软件构建方式的前提下，支持这种多样性很重要。

Everyone, likes different tools, I think it's important to be able to support that while at the same time, you know, kind of using the same way of building software.

在未来，比如五年后，当我们使用不同的后端技术时，你也希望能够轻松替换这些组件。

And then in the future, you know, in five years from now, when we're using different kind of backend technologies, then you want to be able to swap those out as well.

最糟糕的情况是，你已经构建了所有这些内容，却依赖于某个服务，然后不得不到处重写代码来实现变更。

The worst thing is when, you know, you've kind of built all these things and you're dependent upon, you know, some service, and then you have to go rewrite your code everywhere to make it happen.

而使用微插件架构的理念是，你只需要更改插件，在命令行上切换一下，就完成了，你已经替换了整个组件。

And with micro, the idea is all you have to do is change the plugin, switch out on the command line, and that's it, you know, you're kind of done and you've swapped out this entire thing.

是的，我对此进行了深思熟虑。

And, yeah, you know, I was really thoughtful about it.

我希望其他人也能对这个做出回应。

And hopefully, my hope is that other people kind of respond to this.

而且他们也会编写插件，对吧？

And, and they write plugins as well, right?

所以我希望看到社区贡献一些东西。

So I hope to see some stuff contributed from the community.

我们的一个听众提了一个问题，这个问题几乎与此相关。

So one of our listeners has a question and it almost relates to that.

关于你的插件，有多少可以作为组件用于其他可能与微服务无关的项目中？

In terms of your plugins, how many of those can be used as components in other projects that maybe aren't even microservice related?

你能在无关的项目中重用日志包、服务发现之类的组件吗？

Could you reuse the log package or service discovery or something like that in an unrelated project?

你完全可以这么做。

You could totally do that.

它们都是独立的包。

You know, they're all kind of independent packages.

我认为每个包都可以独立使用。

I think so each package can kind of be used independently.

在GoMicro的顶层，唯一的问题是有一个引用服务，将所有内容组合在一起。

There's only the thing of kind of at the top level within GoMicro, have this reference to a service that combines everything.

大部分情况下，如果你想要使用各个独立的部分，是可以的。

For the most part, if you want to use the individual things you can.

而且我认为这也是一个很大的优势。

And I think that's, you know, great benefit there as well.

我实际上看到一些人开始使用Go平台的一些组件，也就是更高层次的工具。

I've actually seen some people, you know, kind of start to use pieces of the Go platform, which is the higher level tooling.

他们正在使用日志指标包或键值存储之类的组件。

And, and, know, they're using the log metrics package or the key value stuff.

这真的很酷。

It's pretty cool.

很好。

Great.

在我们继续之前，我想问问你，阿西姆，人们在哪里可以了解更多关于如何入门的信息？

Before we move on, I wanted to ask you, Asim, where can people find out more in how to get started?

有教程吗？

Are there tutorials?

他们去哪里提问？

Where can they go to ask questions?

你们在Go的Slack上有没有频道？

Do you have a channel here on Go for Slack?

换句话说，告诉我们人们如何开始并熟练使用Micro。

In other words, tell us how people can get started and get proficient using Micro.

当然，谢谢你的提问。

Sure, thanks for asking.

你可以访问网站micro.mu，它会带你到你需要的地方。

So I have, you can go to the website micro.mu, and that'll kind of take you to where you need to go.

网站上有一个博客，包含入门介绍和如何编写Go微服务的入门指南。

So there's a blog which has, the introduction, it has a getting started guide on how to write Go microservices.

你可以访问 GitHub 仓库，那里有一个维基，每个包都有文档，解释了各项功能的工作原理。

You can go to the GitHub repository and there's a wiki and there's documents in every single kind of package that explains how things work.

每个包的 README 都包含一个入门指南，告诉你如何开始使用。

Each of them in the README have a kind of getting started kind of guide and how to start with that.

我们还有一个专门讨论微服务和分布式系统的 Slack 频道。

And we also have a Slack channel dedicated to kind of microservices and distribute systems in general.

任何人都可以自行邀请加入，讨论这些内容。

Everyone can kind of self invite and come join that and talk about this stuff.

我没有在 Gopher 频道中设立一个独立频道的原因是，我知道从长远来看，这不会仅仅局限于 Go 语言。

The reason I didn't actually set up one in the Gopher channel was because I knew that longer term this wasn't going to be solely Go focused.

我们正处在支持多语言的边缘。

We're actually on the cusp of kind of having multi language support.

因此，SIX 和其他一些公司已经开发了 Java 和 Scala 的库。

So SIX and some other companies have developed libraries in Java, Scala.

还有其他人正在独立开发 Rust 版本，我也希望看到 JavaScript 的实现。

Someone else is independently working on Rust, I'm hoping for a JavaScript implementation as well.