代码国际化架构图_图为代码，基础架构为代码-CSDN博客

代码国际化架构图

If you’re working with infrastructure, you’re undoubtedly leveraging infrastructure as code, right? I sure hope so. Otherwise, start now. I’ll be waiting.

如果您使用的是基础架构，那么毫无疑问，您是在利用基础架构作为代码，对吧？我当然希望如此。否则，请立即开始。我会等待。

A natural evolution might be creating a graphical representation of your infrastructure. Diagrams as code if you will. It is not a new idea. This technique appeared in the tech radar back in 2015. You can hark back to that period where people thought that generating code from UML diagrams was a sensible idea.

自然的演变可能是创建基础结构的图形表示。如果愿意，可以将图作为代码。这不是一个新主意。该技术早在2015年就出现在技术雷达中。您可以回溯到那个时代，人们认为从UML图生成代码是一个明智的主意。

Let’s forget that ever happened! Instead, let’s think about using visualization to understand complex architectures. And maintaining those artifacts up to date while we’re at it. I’m going to talk about a tool that builds on top of Graphviz called Diagrams.

让我们忘记曾经发生的一切！相反，让我们考虑使用可视化来了解复杂的体系结构。并在我们使用时保持这些工件最新。我将讨论一种在Graphviz之上构建的名为Diagrams的工具。

什么是图表？ (What is diagrams?)

A tool with a very generic name, that’s for sure. If you check its website, it’s described as:

可以肯定，这个工具的名称非常通用。如果您查看其网站，则描述为：

Diagrams lets you draw the cloud system architecture in Python code.

图表使您可以用Python代码绘制云系统架构。

Pretty straight-forward. Installing it is a one-liner.

非常简单。一口气安装。

pip3 install diagrams

We’re going to create infrastructure diagrams with Python. We’ll commit both the image and the code used to generate them so that everybody in the team can make changes. Let’s get coding, err drawing. I have two examples for you.

我们将使用Python创建基础结构图。我们将同时提交图像和用于生成它们的代码，以便团队中的每个人都可以进行更改。让我们开始编码，绘制错误。我有两个例子供您参考。

警报工作流程 (Alerting workflow)

Let’s say you have a workflow where you publish alarms to an SNS Topic. That topic is processed by a lambda function, which transforms the data and writes it back to Cloudwatch. Through an event rule, the right alerts reach our event bus.

假设您有一个工作流，其中将警报发布到SNS Topic 。该主题由lambda函数处理，该函数转换数据并将其写回到Cloudwatch 。通过事件规则，正确的警报到达我们的事件总线。

So much text for such a little thing. I’m surprised you’re still paying attention. Let me hit you with a fancy diagram.

这么多东西的文字太多了。令您惊讶的是，我很惊讶。让我用花哨的图表打你。

If you check the code, you’ll notice how simple it is. There are three elements.

如果检查代码，您会发现它很简单。有三个要素。

The nodes, which are single components. It has a recognizable icon and a name.
节点，是单个组件。它具有可识别的图标和名称。
The edges, which are the connections between components. They can be directed or undirected.
边缘，即组件之间的连接。它们可以是有向的或无向的。
The clusters, which group nodes logically.
集群，按逻辑对节点进行分组。

And there is not much else. The diagram is built with this snippet.

而且没有什么其他的了。该图是使用此代码段构建的。

from diagrams import Diagram, Cluster


from diagrams.aws.compute import Lambda
from diagrams.aws.integration import SNS, Eventbridge
from diagrams.aws.management import Cloudwatch
from diagrams.onprem.queue import ActiveMQ


with Diagram("Alerting Workflow", show=True):
    with Cluster('main account'):
        topic = SNS('SNS Topic')


        with Cluster('Lambda'):
            l = Lambda('processor')
            topic >> l
            S3('lambda source') - l


        cl = Cloudwatch('Cloudwatch')
        l >> cl


        event = Eventbridge('Cloudwatch\nevent rule')
        cl >> event


    with Cluster('Event Bus'):
        event_bus = ActiveMQ('bus')
        event >> event_bus

Notice how quickly you can get a decent overview of your system with a just bit of Python.

请注意，仅需一点点Python，就能以多快的速度获得对系统的全面了解。

网络图 (Network diagrams)

Networking seems to be uniquely suited for this approach. While researching VPC endpoints, I realized that a clear drawing aids understanding significantly.

网络似乎是唯一适合这种方法的网络。在研究VPC端点时，我意识到清晰的图形可以极大地帮助您理解。

Let’s say we are connecting to a Kubernetes cluster because that’s what we all do these days. We’re routing a bunch of different domains to a VPC endpoint. The cluster resides in a different account, so we use an endpoint service to make it available. Add a few more routes, and the whole thing becomes a tangled mess, much like the pile of cables behind your desk. That is until you see this diagram.

假设我们正在连接到Kubernetes集群，因为这就是我们最近所做的一切。我们正在将许多不同的域路由到VPC端点。群集位于另一个帐户中，因此我们使用端点服务使其可用。再添加几条路线，整个事情就变得一团糟，就像桌子后面的一堆电缆一样。直到您看到此图。

Better, isn’t it? What about the code used to generate it?

更好，不是吗？用来生成它的代码呢？

from diagrams import Cluster, Diagram
from diagrams.aws.network import VPC, PublicSubnet, PrivateSubnet, Endpoint, ELB, Route53
from diagrams.aws.compute import EKS


with Diagram("Connecting two accounts", show=True):
    with Cluster("Account 1"):
        with Cluster("Hosted Zone\nmain.io"):
            star = Route53("*.test.main.io")
            subdomain = Route53("test.main.io")


        with Cluster("Hosted Zone\nalt.dev"):
            alt = Route53("other.alt.dev")


        with Cluster("VPC"):
            VPC()


            with Cluster(""):
                PrivateSubnet()


                endpoint = Endpoint("VPC Endpoint")
                [star, subdomain, alt] >> endpoint


    with Cluster("Account 2"):
        with Cluster("VPC"):
            VPC()


            with Cluster(""):
                PrivateSubnet()


                service = ELB("VPC\nEndpoint Service")
                cluster = EKS("Kubernetes\nCluster")


                endpoint >> service >> cluster

The amount of code used to represent it has grown compared to the previous example. Luckily, using Python gives us access to functions, comprehensions, and other tools to manage this complexity.

与前面的示例相比，用于表示它的代码数量有所增加。幸运的是，使用Python使我们能够使用函数，理解和其他工具来管理这种复杂性。

图表的奇怪情况，无法更新 (The curious case of the diagram that could not be updated)

That’s how you use Diagrams. Is it really valuable? I certainly like the pretty icons. Apart from that, it shines is enabling visual documentation to evolve.

这就是您使用Diagrams的方式 。真的有价值吗？我当然喜欢漂亮的图标。除此之外，它还使可视化文档得以发展。

I’ve tried to digitalize technical diagrams before. I really tried. Sketch, sketchboard, or even just taking a picture of a hand-drawn diagram. It works until you need to update it, and you don’t have the source. Perhaps it was done by somebody else, who preferred a completely different tool. I’ve often seen a project’s documentation get more and more out of date because nobody can update the damn diagrams. If it’s just source code, your chances get a lot better.

之前，我曾尝试将技术图表数字化。我真的尝试过草图，画板，甚至只是拍一张手绘图的照片。它可以工作，直到您需要对其进行更新，并且您没有源。也许是由其他人完成的，他们更喜欢完全不同的工具。我经常看到一个项目的文档越来越过时，因为没人能更新该死的图表。如果只是源代码，您的机会就会大大增加。

结论 (Conclusion)

Diagrams is a neat, albeit limited tool. You can’t add much more than what I’ve shown. While that is constraining, it can protect you from yourself. Overly complicated diagrams do more harm than good. If you are representing the system in its entirety, why not check the code directly? The point of abstraction is to make it simpler to understand by omitting some of the details.

图表是一种整洁的工具，尽管功能有限。您添加的内容不能超过我显示的内容。虽然这样做很受约束，但是它可以保护您免受自己的伤害。过于复杂的图表弊大于利。如果要完整地表示系统，为什么不直接检查代码？抽象的目的是通过省略一些细节使其更易于理解。

In summary, it’s a convenient way to bring clarity into your impenetrable READMEs, and you’ll be able to update the images as your code evolves.

总之，这是将清晰度带入难以理解的自述文件的便捷方法，并且随着代码的发展，您将能够更新图像。

Originally published at https://hceris.com on September 9, 2020.

最初于 2020年9月9日 在 https://hceris.com 上发布。