10分钟了解微服务、容器和Kubernetes
什么是微服务？
什么是微服务？你应该使用微服务吗？微服务与容器和 Kubernetes 有什么关系？如果这些问题在您的日常生活中不断出现，那么这篇文章适合您。
从根本上说，微服务只是一个运行在服务器或虚拟计算实例上并响应网络请求的计算机程序。这与典型的Java、Django、Node.js应用程序没有什么不同。事实上，您可能会发现您的组织中已经部署了十几个微服务。
没有任何新的神奇技术使您的应用程序变成微服务，微服务不是由它的构建方式来定义的，而是由它如何适应更广泛的系统或解决方案来定义的。
那么是什么使服务成为微服务呢？一般来说，微服务的范围更窄，专注于做好较小的任务。让我们通过看一个例子来进一步探索。
让我们看看在Amazon上为您提供产品的页面。它包含几个信息块，可能是从不同的数据库中检索到的：
- 产品描述，包括价格、标题、照片等。
- 推荐项目，即其他人购买的类似书籍。
- 与此项目相关的赞助商列表。
- 关于本书作者的信息。
- 顾客评论。
- 您自己在亚马逊商店中浏览其他商品的历史记录。
如果您要快速编写用于此列表的代码，那么简单的方法将如下所示：
当用户从浏览器发起请求时，它将由Web应用程序（Linux 或 Windows 进程）提供服务。通常，被调用的应用程序代码片段称为请求处理程序。处理程序内部的逻辑将依次多次调用数据库，获取呈现页面所需的信息并将其拼接在一起，然后呈现要返回给用户的网页。
很简单吧？事实上，许多开发类的书籍都有类似这样的教程和示例。那么，你可能会问，为什么要使用微服务把事情复杂化？
想象一下随着应用程序的增长和越来越多的工程师参与其中会发生什么。上面例子中的推荐引擎是由一群程序员和数据科学家维护的。有几十个不同的团队负责渲染该页面的某些组件。这些团队中的每一个通常都希望获得以下自由：
- 更改他们的数据库架构。
- 快速且频繁的将他们的代码发布到生产环境中。
- 使用他们选择的编程语言或数据存储开发工具。
- 在计算资源和开发人员生产力之间做出自己的权衡。
- 拥有自己偏好的维护或监控工具。
可以想象，随着时间的推移，让整个团队就发布应用程序的新版本的所有内容达成一致将变得更加困难。
解决方案是将组件拆分为更小的、独立的服务（又名微服务）。
请求处理程序将传入的页面请求分解为几个专门的请求，并将它们转发给相应的微服务，这些微服务分别使用独立的进程和资源运行。
微服务被分离出来后，每个开发它们的开发团队都可以：
- 随心所欲地部署他们的服务，而不会干扰其他团队。
- 以他们认为合适的方式扩展他们的服务。例如，使用他们选择的 AWS 实例类型，或者可能在专用硬件上运行。
- 拥有自己特定于其服务的监控、备份和灾难恢复。
什么是容器？
从技术上讲，容器只是一个从可执行文件产生的进程，运行在服务器上，它有一些限制，例如：
- 容器不允许看到所有文件系统，它只能访问其中的指定部分。
- 一个容器不允许使用所有的CPU或内存。
- 容器在如何使用网络方面受到限制。
大多数时候，当人们说「容器」时，他们不仅仅指的是Linux进程，还指的是可执行文件的打包和存储方式。
类似的工具Docker允许开发人员获取他们的可执行文件及其依赖项，以及他们想要的任何其他文件，并将它们全部打包成一个文件。这项技术与tarball之类的打包工具没有太大区别。Docker 还允许包含一些额外的指令和配置来运行这个打包的可执行文件。通常这些文件称为镜像。
但为了简单起见，请记住：
- 一个容器是一个Linux进程
- 镜像是Linux可执行文件与它的依赖和配置文件的打包
镜像是可以在任何安装了Docker的机器上运行的，因此容器化技术使得开发人员在不同的环境中部署程序更加容易。
微服务和容器有什么区别？
我们刚刚了解到容器只是一种打包、部署和运行程序或者进程的方法。您可以将一个巨大的单体应用程序作为容器，也可以拥有一群完全不使用容器技术的微服务。
容器是一种有用的资源分配和共享技术。这是开发运维人员感到兴奋的事情。
微服务是一种软件设计模式。这是开发人员感到兴奋的事情。
它们是相关的，但不需要彼此。您可以将单体应用部署为容器，也可以拥有不受限制的、非容器化的微服务。
什么时候使用微服务？
微服务背后的想法并不新鲜。十几年来，软件架构师一直致力于将单体应用程序分离为可重用的组件。
微服务的好处很多，包括：
- 更简单的自动化测试。
- 快速灵活的部署模式。
- 更高的整体弹性。
采用微服务的另一个好处是能够为工作选择最佳工具。应用程序的某些部分可以从 C++ 的速度中受益，而其他部分可以从更高级别语言（例如Python或JavaScript）的生产力提高中受益。
微服务的缺点包括：
- 需要更仔细的规划。
- 更高的研发投入。
- 过度工程的诱惑。
如果应用程序和开发团队足够小并且工作量不具有挑战性，则通常无需使用微服务。但是，如果您开始看到微服务的利大于弊，这里有一些具体的设计注意事项：
-
计算和存储分离
随着您对 CPU 能力和存储需求的增长，这些资源具有非常不同的扩展成本和特性。从一开始就不必依赖本地存储，这将使您能够相对轻松地适应未来的工作负载。这既适用于文件系统等简单的存储形式，也适用于数据库等更复杂的解决方案。
-
异步处理
通过添加越来越多的相互调用的子程序或对象来逐步构建应用程序的传统方法随着工作负载的增长而停止工作，并且应用程序本身必须跨多台机器甚至数据中心扩展。将需要围绕事件驱动模型重新构建应用程序。
-
拥抱消息总线
随着您的单体应用程序被分解为事件处理程序和事件发射器，就需要一个健壮、高性能和灵活的消息总线。有多种选择，选择取决于应用程序规模和复杂性。对于一个简单的应用，像Redis这样的东西就可以了。如果您的应用程序足够复杂，您可能需要一个Kafka。
-
API 版本控制
由于您的微服务将使用彼此的 API 通过总线相互通信，因此设计用于保持向后兼容性的架构将是至关重要的。开发团队必须在永远支持旧 API 和保持更高的开发速度之间达成合理的妥协。这也意味着 API 设计成为一项重要的技能。频繁的API更改是团队无法高效开发复杂微服务的原因之一。
-
重新考虑您的安全性
许多开发人员没有意识到这一点，但迁移到微服务为更好的安全模型创造了机会。由于每个微服务都是一个专门的进程，因此最好只允许它访问所需的资源。这样，仅一个微服务中的漏洞就不会将系统的其余部分暴露给攻击者。
Kubernetes 与微服务有什么关系？
Kubernetes太复杂了，在本文中不会详细描述，但值得对其进行概述，因为很多人在有关微服务的对话中都会提到它。
严格来说，Kubernetes（又名 K8s）的主要好处是通过跨多个进程高效共享计算资源来提高基础设施利用率。Kubernetes是动态分配计算资源以满足需求的大师。这允许组织避免为他们不使用的计算资源付费。
当您将单体应用程序分解为单独的、松散耦合的微服务时，您的团队将获得更多的自主权和自由度。然而，在与运行微服务的基础设施进行交互时，他们仍然必须密切合作。
您必须解决以下问题：
- 预测每个服务需要多少计算资源。
- 这些要求在负载下如何变化。
- 如何划分基础设施分区并将它们划分到微服务之间。
- 实施资源限制。
Kubernetes非常优雅地解决了这些问题，并提供了一个通用框架来描述、检查和推理基础设施资源的共享和利用。这就是为什么采用Kubernetes作为微服务架构的一部分是一个好主意。
然而，Kubernetes是一项需要学习的复杂技术，而且更难管理。如果允许，您可以利用第三方提供的服务，我们建议尝试使用 StarOS，这是一个一站式云原生在线开发平台，底层技术基于Kubernetes。
StarOS 通过架构图模型，将微服务的依赖关系固化，完成了对整个应用的封装，从而实现了应用与环境的解耦。无论是应用复制，还是应用迁移，都得心应手。并且基于基础设施下沉的理念，将底层的容器集群资源、运维管理工具，以及中间件、环境配置等全部下沉为平台能力，真正做到了一站式，而且开箱即用。
StarOS 还为研发团队提供了多职能、多场景的多人在线协作研发工具，支持研发工作中多种输出物的在线编辑交付，让您在异地协同，远程办公的时候，尽享便利。
总结一下：
- 容器只是具有应用限制的Linux进程，限制的示例包括允许进程使用多少CPU或内存。Docker允许开发人员将他们的可执行文件与依赖项和附加配置打包在一起，这些包被称为镜像。
- 微服务并不新鲜，这是一种软件设计模式，由于互联网公司的规模不断扩大，它越来越受欢迎。微服务不一定要容器化，类似地，单体应用程序可以是微服务。
- 小项目不应该回避整体设计。它为较小的团队提供更高的生产力。
- Kubernetes是由多个微服务组成的复杂应用程序的绝佳平台。
- Kubernetes是一个复杂的系统。