微服务架构是一个怎样的存在？

file

一篇关于构建大规模应用的介绍

一篇关于构建大规模应用的介绍

介绍

无论现在的影响力如何，分布式系统仍然是最容易被忽视的主题之一，至少在大学层面是如此。没有多少学生理解诸如容器化和容错等概念，你也永远不会看到系统项目赢得黑客马拉松。尽管如此，我认为至少对今天的大规模系统如何工作有一个简单的理解是非常重要的。

这个故事是针对初学者的系列中的第一个，例如接受 1 到 2 年级的普通计算机科学教育或者具有自学网络开发经验的人。前几篇文章将对主要概念进行重点介绍，并深入探讨技术细节。然后，我希望探索网络相关的主题、Kubernetes ，以及我在研究中看到的有趣内容。第一个非常简单，旨在解释微服务背后的动机和基本概念。

分布式系统维持着互联网的运行

在过去，应用程序都是独立的。可能应用程序包括Web服务本身和储存系统被打包成只有一个或者两个二进制文件。然后这些二进制文件上传到服务器直接在机器上运行。在 80，90 年代这个系统是足够的，但是如今 Google 每天都会收到 35 亿次搜索查询，没有哪个服务器足够强大到处理这些查询。

过去，工程师购买更好的服务器，更好的电缆等等。随着互联网的发展和摩尔定律的终结, 这种方法很快变得不可行了，很明显需要横向拓展而不是纵向。取而代之，不再去买更好的更贵的硬件，而是去买大量便宜的服务器去分配这些负载。

最早的横向拓展只是运行多个 Web 服务的副本。然而随着云服务的发展，微服务 架构很快主导了市场。微服务是指将一个大的应用拆分成独立的组件，叫做服务，每个组件执行一项专门的任务。所以不是让一个 Web 服务从头到尾运行处理一个请求，开发人员将应用拆分成服务像用户身份验证, 页面服务，API 服务，数据库模型服务等等。

file

拆分一个独立应用程序 (Source: Dzone)

每一个微服务有一个或者多个 微服务 组成。对于运行在 Django 上的网站，我们可以通过增加我们运行在 Django 服务器的副本数量来进行横向拓展。这些副本是完全一样的。如果我们运行一个数据库，我们可以通过增加副本数量来增加副本，我们通常称之为分片。 将分片视为数据库的一部分，你可以独立运行并保留整体数据的一部分。通过增加分片数量，我们可以横向拓展数据库。这些副本可以在不同机器上运行。所以如果我们想在 100 台机器上运行一个大的 Web 服务，我们可以让 100 份副本单独在每一台机器上运行。

让我们看一个完整的例子。负载均衡器可以接受谷歌搜索查询，并将其转发到 api 服务器的数千个副本之一。然后，api 服务器将请求同时转发给索引器、ad 生成器和 ML 神经网络。每个服务都可以运行数千个副本。这些单独的服务完成它们自己的任务，每个任务都是整个原始请求的一部分，然后 api 服务器聚合结果并以搜索结果的形式返回给您。

file

聚合样式的微服务体系结构 (Source: Arun Gupta)

有关微服务体系结构模式的更多信息，请访问 Arun Gupta's Blog。他是 AWS 的首席技术专家。

优势

下面是一些比较关键的优势。当然还有很多其它的优势，但这四个最为重要。

微服务框架最重要的不可否认的优势是可以横向拓展任何组件。如果一个服务（例如神经网络）负载很重，你可以简单的运行该服务的更多的副本。
服务是独立的。每个组件可以存在于独立的库中，并由专门的工程师团队维护。每个组件可以用最适合它的语言编写，比如数据库服务用 C 语言编写 Web 服务用 Python 编写。组件的更新和新组件的编写不会影响其它的服务。
架构是可插拔的。基于服务独立性构造的，但它带来的是一个全新的境界。一个公司甚至不需要写出所有的服务。第三方应用像 MySQL，Elasticsearch，Redis 全是可以很容易整合到你系统的微服务。
容错（通过错误隔离）。这种优势只有在你的系统设计不合理时才得以体现。一个副本的故障不会导致整个管线故障甚至停止服务。同样的，特定服务中的错误不会影响其它无关服务的正常运行。这并不总是容易的，容错是工业和研究里的一个难题，特别是对分布式数据库和网络。

当然，和所有事情一样，微服务也有一些缺点。将请求从一台服务器转发到另外一台服务器，这具有一定的开销和复杂性。分布式系统通常都存在依赖、复制和共享问题。随着微服务的数量和复杂增加，部署和调试的难度也呈指数级增加。

好消息是，有大量的研究人员，公司和创业公司在一起合力研究这些问题。Jenkins，Spinnaker 和 Jaegertracing 等项目都是今天最流行的开源解决方案之一，每天在行业和学术中都有新的创新。

所以，分布式系统仍可以说是相对比较新的，其影响力也在每日剧增。
我的意思是，仅仅想想你是如何来阅读这篇文章的。