从容器化编排到代理，一个完整的微服务架构总共分几步？

Posted 2021-04-14 优云数智

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了从容器化编排到代理，一个完整的微服务架构总共分几步？相关的知识，希望对你有一定的参考价值。

导读：

小数推荐微服务的文章不少，比如《》、《》微服务对于开发者和企业IT人员一提起就头疼，如何下手？是不是个坑？实施到什么程度可以称之为微服务？本文相对浅显，有效微服务架构的10块拼图，让大家感性的感知一下微服务。

任何人都可以提供一项小小的服务。这是你在“Hello World”express服务器上做的第一件事。如果你以前做过“Hello World”express服务器，那么恭喜！你已经做了一个微服务！从一个到很多，问题开始堆积如山。

他们应该如何通信? REST? RPC ? Messaging? 为什么要选择一个而不是另一个呢?

比方说，你设法连接了一些服务的小系统，选择REST是因为它看起来最简单。是时候把它们部署到某个地方了。如果尝试在一个平台上运行微服务(PaaS)，（如Modulus或Heroku），这会花费很多时间，而且非常昂贵。

更不用提通过互联网而不是专用网络进行通信的延迟了。这是不行的。你需要提供环境变量，以便知道要ping什么端点。

然后考虑部署。部署总是痛苦的，现在你需要做七次?!

上面的场景基本上是我第一次尝试的样子。我使用了单向数据流!可惜这只是其中的一个片段。

那么日志记录呢?监控呢?在哪里存储secrets?如何自动伸缩?

你终于意识到，除了想要提供微小的服务之外，还需要学习如何在AWS上建立自己的基础设施。

突然间，我们的小服务不再那么渺小了。

它更多地追踪资源和学习每个资源，以及它们如何交互构成大部分学习曲线。

以下工具组合起来有可能大大提高开发服务、部署以及在任何环境中运行的便利。一旦它们被编码，就可以重用。

它更多的是跟踪资源和学习，以及如何交互构成大部分学习曲线。

1、容器化

没有容器，就不能有效地构建微服务。

想象一下，如果你想买一些奥利奥，他们会分开来。至少，这是不太方便的。

当涉及到服务时，容器简化了开发、测试、部署和在生产中运行。所有你每天需要做的事情作为你的工作，不妨让它变得更容易。

服务需要容器，就像奥利奥一样。

工具：Docker

2、集群

想象一下，如果你必须独自把所有的杂货都搬回家。你把它们放进袋子里，重的放在底部，这样他们就不会把面包和冷的东西压在一起。有些东西你会双重包装，因为冗余。

包就像服务器一样，你需要的不止一个，而且他们还保留着你的服务。

拥有多个可以避免故障的情况，例如可用区域出现故障。比如，你的汤可能破损，纸袋撕裂。幸好你双袋装的，给自己鼓个掌！

可以在任何主要的云提供商那里获得服务器。这里最重要的是codify基础设施。有几种不同的方法可以做到这一点。在过去，许多人使用Ansible来实现这一点，但是考虑到快速扩展性的要求，必须等待服务器的启动和配置。相反，你可以使用安装的所有工具“烘烤”机器的图像，然后将该图像与Terraform或Cloudformation一起使用。一旦设计了集群的弹性，新的AMI的滚动更新将允许更新整个基础设施。

服务器：AWS, Azure，DigitalOcean

工具：Cloudformation, Terraform, Packer

3、编排工具

编排工具就像杂货店的手袋一样。

编排器知道你的服务的内存需求，以及需要分配多少CPU，并且仔细地将每个服务放到适当的服务器中。

工具：Docker Swarm，Kubernetes

4、持续部署

部署非常耗时，并且你有更好的事情要做。

自动化，自动化，自动化。

这直接有助于赚钱的业务。整个精益创业是关于建立，测量，学习和重复这个循环。持续部署可以更快地完成此任务。你可以越快越好，因为那样你就可以衡量，学习，并知道下一步要做什么。

我个人认为你应该努力让所有事情自动化。Git流在一组小服务中重复15次时太麻烦了。当你需要的时候可以做分支，但是，如果你有适当的安全检查，可以直接承诺。

工具: Jenkins (Withpipeline and Blue Ocean), TravisCI, CircleCI

5、代理

你的服务应该是安全的。

不要把你的服务直接暴露在互联网上!

相反，使用面向公众的反向代理。它必须是一个易于配置的应用程序，理想情况下，可以基于服务中定义的某些配置选项来自我配置，因此开发该服务的团队可以决定如何与代理进行交互，而不需要ssh到服务器。

工具：HAProxy, nginx, docker-flow-proxy

6、消息队列

服务应该以通用语言进行通信。消息队列可以用作向所有订阅的客户端发送消息的粘合剂。此外，服务的责任不应该是知道其他服务在哪里运行。如果他们动了，那么你就需要知道。

当然，你可以使用像Consul这样的分布式密钥存储库，并使其保持最新，以避免不断地重新配置服务，或者更好地使用编排器的DNS特性和使用REST，但是，这仍然需要额外的职责和配置。使服务紧密耦合。

使用one-wayfire 和forget messages，使服务松散耦合，并且易于扩展。

相反，使用消息队列，你可以简单地以“fire and forget”方式发送或发布消息。其他服务可以轻松地添加或删除，而不影响原始的发布服务。这使得你的架构也很容易扩展。此外，通过重试和错误队列等功能，可以减轻服务崩溃的压力。当服务恢复时，消息将简单地重新尝试。

工具:RabbitMQ,ActiveMQ, AWSMQ, ZeroMQ。

7、集中化的日志

通过跨多个节点和许多副本发生的消息，可能由调度器移动，这不是ssh到服务器并检查日志的可行选项。需要将它们发送到一个集中的位置，在那里可以容易地搜索它们，并深入了解代码在生产中的功能。

在一个地方看到一切。

此外，了解如何运送（ship）日志不应该是服务的责任。相反，请始终登录到stdout或stderr，并使用工具在集群中的每个节点上运行来收集所有日志。日志收集器工具将日志发送到集中的日志子系统。

工具: ELK Stack(ElasticSearch, Logstash, Kibana)

8、监测和报警

同样地，对于日志记录，不希望追踪服务查看使用情况统计信息。相反，应该将所有这些信息收集并运送（ship）到一个集中的位置。

在人工警报之前，使用报警来驱动扩展或恢复事件。

如果不需要，也不愿意追踪这些信息。理想情况下，只有在出现问题时才能听到警报声音。需要一个报警工具，响应从监控中收集的指标并提醒用户。而且，它可以警报微服务来触发扩展事件，或尝试以其他方式解决该问题以避免需要人工交互。

Tools: Prometheus, Alertmanager, Grafana

9、元存储库

大多数人只听说过monorepos，或multi-repos，两者都符合某些要求。然而，使用微服务，往往会有很多monorepos需要处理。使用元存储库可以通过创建parent repository和命令行工具来解决这个问题，同时在多个存储库中执行命令。

Tools：meta, gitslave

10、微服务思维

构建基础架构时，架构师的工作并没有完成。为了让架构发挥出其好处，团队需要接受微服务。架构目标中的所有工具都是通过支持适合这项工作的语言来保持灵活性，这是由于消息总线和容器化的松耦合。如果团队只是去建立庞然大物，并称之为微服务，那么它不会起作用。因此，他们需要接受有关微服务设计模式和优势的教育，给团队信心让他们放心地进行建设。

结论

以上对微服务架构的组件有了一个大致的概述。作为架构师，需要大量的工具来学习，这是一个困难的过程，但是，利用整个架构的力量会给你发展的超能力！

原文链接：

The 10Puzzle Pieces of an Effective Microservice Architecture

https://hackernoon.com/what-makes-a-microservice-architecture-14c05ad24554