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