问题描述
为什么不使用 ASN.1 进行微服务之间的通信？
选择 JSON 或 Protobuf 而不是 ASN.1 的技术原因是什么？
解决方法
在我看来，
您将选择 JSON 或 Protobuf 的原因与您的祖先选择 SOAP 针对 ASN.1 和 CORBA 而不是 ASN.1 的原因相同
受欢迎程度：有多少开发者在做贡献......你能在论坛上获得支持......等吗？
工具：您能否依靠现有工具以特定编程语言生成存根……最好是开源的？
请记住 ASN.1 是（仅）一组规范......每次你发现 ASN.1 在定义中更强大时，你都会遇到同样的问题：我可以使用什么工具来生成我的代码？ ...
,如今选择 ASN.1 可能意味着选择 JSON； JSON 现在是 ASN.1 的有线格式之一！
架构
然而，专注于模式语言，就我所见，当涉及到我认为是必不可少的东西时，即对值和列表大小的约束，JSON 模式与 ASN.1 模式一样强大。 ASN.1 的约束可能非常复杂——这也是难以实现工具的原因之一。 Protobuf 模式在这方面严重不足；没有限制，您必须依靠其他一些方法让程序员了解值的有效限制或列表的可接受长度。 ASN.1 模式的一个特性是您可以声明值以及消息类型，并且在好的工具中这些值显示在生成的代码中。如果使用得当，它非常强大，因为您可以在一个地方（模式文件）定义更多系统常量，而不是用系统中使用的各种不同编程语言进行硬编码。您可以围绕此获得非常敏捷的工作流程。
电线格式
专注于有线格式，好吧，ASN.1 赢得了胜利，具有一系列不同的二进制有线格式，可满足许多不同的需求，包括 XML 和 JSON 文本格式。我认为 Protobuf 现在可以执行 JSON，并且它具有二进制有线格式。 JSON 就是 JSON。
ASN.1 在拥有如此多不同的有线格式方面如此有用的原因是，在某些系统类型中，可以方便地以 JSON/XML 表示数据，而其他类型则受益于 uPER（一种超-紧凑位高效的二进制线格式）。例如，如果您通过带宽受限的链接发送数据，uPER 非常方便，因为您可以充分利用该带宽，但您可以在端点以 XML 或 JSON 等（半）可读格式存储它。这些工具使得将对象从一个转换为另一个变得微不足道（从一种有线格式反序列化，将对象序列化为另一种有线格式，工作完成）。有趣的是，ASN.1 是由电话业务发明的，用于蜂窝电话网络标准，专门用于节省带宽（从而节省成本）。
像 BER 这样的有线格式的其他好处是，您无需阅读整个消息就可以知道正在接收的消息类型；我发现这在复杂系统中非常非常有用。
工具
正如 YaFred 所说，这取决于工具。 ASN.1 的最佳工具是商业工具，您必须将许可管理集成到构建和部署中。但是，考虑到 ASN.1 可以获得而 Protobuf 无法实现的高度开发敏捷性，我发现项目成本节省绝对值得。 This one (C only,includes source) 很好而且价格实惠，但如果预算达到几千美元，我会认真考虑 this one，因为它支持的语言（C/C++、C#、Java、Python、去）
如果您对 C 感到满意，那么有一个相当不错的 ASN.1 编译器 here。目前，这不做 ASN.1 值，并且它在其约束处理（特别是 <）方面有一些遗漏，就敏捷工作流而言这是一个遗憾，但除此之外还是不错的。它是 OSS，因此原则上您可以自己修复这些遗漏，不会有太大困难（它写得很好，而且很容易插入额外的点点滴滴）。
来吧，谷歌
对我来说，也许最好的前进方式是让 Google 醒来并更新 Protobuf。他们甚至可以在不触及他们的有线格式的情况下这样做。虽然他们的有线格式很笨拙，但对 Protobuf 的语言支持非常好，而且免费，所以它有点属于“足够好”的范畴。
但如果他们向模式和代码生成器添加甚至简单的值和列表约束以及值定义；那么它将是“完整的”，因为它可以拥有与 ASN.1 相同的非常敏捷的工作流程，但在 GPB 的免费工具生态系统中。
我记得在 Google 宣布 GPB 时读到，会议观众中有人喊道：“你为什么不使用 ASN.1？”。 Google 员工声称他们为 GPB 所“发明”的所有优点（紧凑的数据表示、语言独立性等）都是 ASN.1 及其工具几十年来一直牢牢抓住的东西，他们不得不承认 Google从未听说过 ASN.1。哦，讽刺的是。基本上，如果 Google 决定免费实施 ASN.1 而不是 GPB，他们会得到更好的结果。