什么是微服务？

什么是微服务？你应该使用微服务吗？微服务和容器、kubernetes是什么关系？如果这些问题在你的日常生活中不断出现，那么这篇文章就适合你。

基本上，微服务只是在服务器或虚拟计算实例上运行并响应网络请求的计算机程序。这与典型的 Java、Django、node 没有什么不同。JS 应用程序。事实上，您可能会发现您的组织中已经部署了十几个微服务。

没有新的魔法技术可以将您的应用程序转变为微服务。定义微服务的不是它们的构建方式，而是它们如何适应更广泛的系统或解决方案。

那么是什么让服务成为微服务呢？一般来说，微服务的范围比较窄，专注于小任务。让我们通过一个例子来进一步探索。

让我们看一下在亚马逊上为您提供产品的页面。它包含几个可以从不同数据库中检索到的信息块：

• 产品描述，包括价格、标题、照片等。
• 推荐物品，即他人购买的类似书籍。
• 与该项目相关的赞助商名单。
• 关于本书作者的信息。
• 客户意见。
• 浏览亚马逊商店中其他产品的历史。

如果你想快速为这个列表写代码，简单的方法如下：

当用户从浏览器发起请求时，它由 Web 应用程序（Linux 或 Windows 进程）提供服务。通常，调用的应用程序代码片段称为请求处理程序。Handler内部的逻辑会依次调用数据库多次，获取渲染页面所需的信息，拼接在一起，然后渲染网页返回给用户。

这很简单，不是吗？其实很多开发书籍都有这样的教程和例子。那么，您可能会问，为什么要使用微服务来使事情复杂化？

 

想象一下随着应用程序的增长和更多工程师的参与会发生什么。上述示例中的推荐引擎由一组程序员和数据科学家维护。有几十个不同的团队负责渲染页面的某些组件。这些团队中的每一个通常都希望获得以下自由：

1. 更改他们的数据库架构。
2. 快速、频繁地将他们的代码发布到生产环境。
3. 使用他们选择的编程语言或数据存储开发工具。
4. 在计算资源和开发人员生产力之间做出自己的权衡。
5. 拥有自己喜欢的维护或监控工具。

可以想象，随着时间的推移，整个团队就发布新版本应用程序的所有内容达成一致会变得更加困难。

解决方案是将组件拆分为更小的独立服务（也称为微服务）。

请求处理程序将传入的页面请求分解为几个特殊的请求，并将它们转发给相应的微服务，这些微服务以独立的进程和资源运行。

微服务分离后，每个开发微服务的开发团队可以：

• 在不干扰其他团队的情况下随意部署他们的服务。
• 在他们认为合适的时候扩展他们的服务。例如，使用他们选择的 AWS 实例类型，或者可能在专用硬件上运行。
• 拥有针对其服务的自己的监控、备份和灾难恢复。

什么是容器？

从技术上讲，容器只是一个从可执行文件生成并在服务器上运行的进程。它有一些限制，例如：

• 不允许容器查看所有文件系统。它只能访问其中的指定部分。
• 一个容器不允许使用所有的 CPU 或内存。
• 容器在使用网络的方式上受到限制。

大多数时候，当人们说“容器”时，他们所指的不仅仅是Linux进程，还包括可执行文件的打包和存储。

一个类似的工具 docker 允许开发人员获取他们的可执行文件及其依赖项，以及他们想要的任何其他文件，并将它们全部打包到一个文件中。该技术与 tarball 等打包工具没有太大区别。Docker 还允许您包含额外的指令和配置来运行打包的可执行文件。这些文件通常称为镜像。

但为简单起见，请记住：

• 容器是一个 Linux 进程
• 映像是 Linux 可执行文件及其依赖项和配置文件的打包

镜像可以在任何安装了 docker 的机器上运行，因此容器化技术使得开发者可以更轻松地在不同环境中部署程序。

微服务和容器有什么区别？

我们刚刚了解到容器只是打包、部署和运行程序或流程的一种方式。您可以将一个巨大的单个应用程序用作容器，也可以拥有一组根本不使用容器技术的微服务。

容器是一种有用的资源分配和共享技术。这是让开发人员和运维人员兴奋的事情。

微服务是一种软件设计模式。这是开发人员感到兴奋的事情。

它们是相关的，但不需要彼此。您可以将单个应用程序部署为容器，也可以拥有无​​限的非容器微服务。

什么时候使用微服务？

微服务背后的想法并不新鲜。十多年来，软件架构师一直致力于将单个应用程序分离为可重用的组件。

微服务有很多好处，包括：

• 更简单的自动化测试。
• 快速灵活的部署方式。
• 更高的整体弹性。

采用微服务的另一个好处是能够为工作选择最佳工具。应用程序的某些部分可以受益于 C++ 的速度，而其他部分可以受益于 Python 或 JavaScript 等高级语言提高的生产力。

微服务的缺点包括：

• 需要更仔细的计划。
• 研发投入较高。
• 过度工程的诱惑。

如果应用和开发团队足够小，工作量不大，通常不需要微服务。但是，如果您开始看到微服务的优点大于缺点，这里有一些具体的设计注意事项：

1. 计算与存储分离

   随着您对 CPU 功率和存储需求的增长，这些资源具有非常不同的扩展成本和特性。您不必从一开始就依赖本地存储，这将使您相对容易地适应未来的工作负载。这不仅适用于文件系统等简单的存储形式，也适用于数据库等更复杂的解决方案。

2. 异步处理

   传统的通过添加越来越多的子程序或相互调用的对象来逐步构建应用程序的方法随着工作量的增加而停止工作，应用程序本身必须扩展到多台机器甚至数据中心。您将需要围绕事件驱动模型重建您的应用程序。

3. 拥抱消息总线

   由于您的单个应用程序被分解为事件处理程序和事件发射器，因此您需要一个健壮、高性能和灵活的消息总线。有很多选择，具体取决于应用程序的大小和复杂性。对于一个简单的应用程序，redis 之类的东西是可以的。如果您的应用程序足够复杂，您可能需要 Kafka。

4. API 版本控制

   由于您的微服务将使用彼此的 API 通过总线相互通信，因此设计一个向后兼容的架构至关重要。开发团队必须在始终支持旧 API 和保持更高的开发速度之间达成合理的折衷。这也意味着API设计已经成为一项重要的技能。频繁的 API 更改是团队无法高效开发复杂微服务的原因之一。

5. 重新考虑您的安全性

   许多开发人员没有意识到这一点，但迁移到微服务为更好的安全模型创造了机会。由于每个微服务都是一个专用进程，因此最好只允许它访问所需的资源。这样，只有一个微服务中的漏洞不会将系统的其余部分暴露给攻击者。

Kubernetes和微服务是什么关系？

Kubernetes 过于复杂，本文无法详细描述，但值得总结一下，因为很多人在谈论微服务时都会提到它。

严格来说，kubernetes（也称为 k8s）的主要好处是通过跨多个进程有效共享计算资源来提高基础设施利用率。Kubernetes 是动态分配计算资源以满足需求的大师。这允许组织避免为他们不使用的计算资源付费。

当您将单个应用程序分解为单独的、松散耦合的微服务时，您的团队将获得更多的自主权和自由度。但是，在与运行微服务的基础架构交互时，它们仍然必须密切合作。

您必须解决以下问题：

• 预测每个服务需要多少计算资源。
• 这些要求在负载下如何变化。
• 如何划分基础设施并在微服务之间划分它们。
• 实施资源约束。

Kubernetes 优雅地解决了这些问题，并提供了一个通用框架来描述、检查和推理基础设施资源的共享和利用。这就是为什么采用 Kubernetes 作为微服务架构的一部分是个好主意。

但是，kubernetes 是一项复杂的技术，学习起来也比较困难。如果允许，您可以利用第三方提供的服务。推荐尝试StarOS，这是一个一站式的云原生在线开发平台，底层技术基于kubernetes。

Staros通过架构图模型固化微服务的依赖关系，完成对整个应用的封装，实现应用与环境的解耦。应用程序复制和应用程序迁移都很方便。基于基础设施下沉的理念，将底层容器集群资源、运维管理工具、中间件、环境配置等全部下沉到平台能力中，真正做到一站式、开箱即用。

Staros还为研发团队提供了一款多功能、多场景的多人在线协同研发工具，支持研发工作中多种输出的在线编辑和交付，方便您进行协作在不同的地方和远程工作。

总结一下：

1. 容器只是具有应用程序限制的 Linux 进程。限制的示例包括允许进程使用多少 CPU 或内存。Docker 允许开发人员将其可执行文件与依赖项和附加配置打包在一起，这些配置称为镜像。
2. 微服务并不新鲜。它是一种软件设计模型。由于互联网公司规模的不断扩大，越来越受欢迎。微服务不必容器化。同样，单个应用程序可以是微服务。
3. 小项目不应该回避整体设计。它为较小的团队提供了更高的生产力。
4. Kubernetes 是由多个微服务组成的复杂应用程序的绝佳平台。
5. Kubernetes 是一个复杂的系统。