You Want Modules, Not Microservices
Ted Neward argues the microservices pitch is recycled: of six quoted benefits, two come from microservices literature, two from twenty-year-old EJB material, and two from Oracle Tuxedo, forty-year-old technology. Strip the branding and what remains is the module — an independently built, versioned, deployed and reusable unit of code, the concept Parnas defined in 1971 and Unix pipes-and-filters delivered in the 1970s. What organizations actually bought was organizational clarity: small teams owning their own analysis, testing, data and deployment dependencies instead of waiting on DBA, QA or infrastructure groups, at the cost of full-stack staffing and on-call duty. Technically, in-process module calls become network calls, adding five to seven orders of magnitude of latency and running into the Fallacies of Distributed Computing, which more nodes only worsen. Neward's advice: any decomposition behind a common API convention works; fix organizational dependencies directly. Suited to architects and tech leads.
02 January 2023
tl;dr Architecture is hard sometimes--people keep offering up some new idea that quickly becomes the mainstream "way to do it" without any context or nuance, and the industry, desperate to find ways to improve their architecture, snaps it up without hesitation. Microservices was the latest in the trend, and it's time we dissected the idea and got to the real root of what's going on.
2023 年 1 月 2 日
简而言之：架构有时很难——人们不断提出某种新想法，它很快成为主流的“做法”，却不带任何背景或细微差别；而业界急于寻找架构改进之道，便毫不犹豫地全盘接受。微服务是这股趋势中的最新一波，是时候剖析这个概念，弄清它背后真正发生了什么。
At the heart of microservices, we're told we'll find...
... Lots of Good Things (TM)!
"Scalability": "Code can be broken into smaller parts that can be developed, tested, deployed, and updated independently."
"Focus": "... developer focuses on solving business problems and business logic."
"Availability": "back-end data must always be available for a wide range of devices... ."
"Simplicity": "provides simplified development of large scale enterprise level application."
"Responsiveness": "... enables distributed applications to scale is response to changing transaction loads... ."
"Reliability": "Ensures no single point of failure by providing replicated server groups that can continue when something breaks. Restores the running application to good condition after failures occur."
These all sound relatively familiar, I'd imagine, but the fun part about those six quotes is that two were taken from microservices literature (blog posts, papers, etc), two from twenty-years-ago EJB literature, and two from Oracle Tuxedo, which is forty-plus-years-ago technology. Can you spot which went to which?
We have a tendency in this industry to re-use our hype points over and over again.
"Those who cannot remember the past are condemned to repeat it." --George Santanyana, The Life of Reason (1905)
在微服务的核心，据说我们会发现……
……一大堆好东西（TM）！
“可扩展性”：“代码可以拆成更小的部分，独立开发、测试、部署和更新。”
“专注”：“……开发者专注于解决业务问题和业务逻辑。”
“可用性”：“后端数据必须始终可供各种设备使用……。”
“简单性”：“为大规模企业级应用提供简化的开发方式。”
“响应能力”：“……让分布式应用能够随着交易负载的变化而扩展……。”
“可靠性”：“通过提供复制的服务器组，确保没有单点故障，在出问题时仍能继续运行。故障发生后，将运行中的应用恢复到良好状态。”
这些听起来应该都挺熟悉，但这六段引文的有趣之处在于：其中两段来自微服务文献（博客文章、论文等），两段来自二十年前的 EJB 文献，还有两段来自 Oracle Tuxedo——那是四十多年前的技术。你能分辨出哪段来自哪里吗？
我们这个行业有一种倾向：反复回收利用自己的炒作点。
“那些不能记住过去的人，注定要重蹈覆辙。”——乔治·桑塔亚那，《理性的生活》（1905）
With respect to the microservices hype, one company's blog post offers 10 reasons to charge into microservices:
They promote big data best practices. Microservices naturally fit within a data pipeline-oriented architecture, which aligns with the way big data should be collected, ingested, processed and delivered. Each step in a data pipeline handles one small task in the form of a microservice.
They are relatively easy to build and maintain. Their single-purpose design means they can be built and maintained by smaller teams. Each team can be cross-functional while also specialise in a subset of the microservices in a solution.
They enable higher-quality code. Modularising an overall solution into discrete components helps application development teams focus on one small part at a time. This simplifies the overall coding and testing process.
关于微服务的炒作，某家公司的博客文章列出了十条理由，呼吁人们投身微服务：
它们推动大数据最佳实践。微服务天然契合面向数据管道的架构，这与大数据应当被收集、摄入、处理和交付的方式一致。数据管道中的每一步都以微服务的形式处理一个小任务。
它们相对容易构建和维护。单一用途的设计意味着可以由更小的团队来构建和维护。每个团队既可以跨职能，也可以专注于解决方案中某个微服务子集。
它们带来更高质量的代码。把整体解决方案模块化为离散组件，有助于应用开发团队一次只专注一小部分。这简化了整体编码和测试过程。
They simplify cross-team co-ordination. Unlike traditional service-oriented architectures (SOAs), which typically involve heavyweight inter-process communications protocols, microservices use event-streaming technologies to enable easier integration.
They enable real-time processing. At the core of a microservices architecture is a publish-subscribe framework, enabling data processing in real time to deliver immediate output and insights.
They facilitate rapid growth. Microservices enable code and data reuse the modular architecture, making it easier to deploy more data-driven use cases and solutions for added business value.
它们简化跨团队协作。与通常涉及重量级进程间通信协议的传统面向服务架构（SOA）不同，微服务使用事件流技术来实现更轻松的集成。
它们支持实时处理。微服务架构的核心是发布-订阅框架，能够实时处理数据，立即交付输出和洞察。
它们促进快速增长。微服务借助模块化架构实现代码和数据复用，从而更容易部署更多数据驱动的用例和解决方案，创造额外商业价值。
They enable more outputs. Data sets often are presented in different ways to different audiences; microservices simplify the way data can be extracted for various end users.
Easier to assess updates in the application life cycle. Advanced analytics environments, including those for machine learning, need ways to assess existing computational models against newly created models. A-B and multivariate testing in a microservices architecture enable users to validate their updated models.
They enable scale. Scalability is about more than the ability to handle more volume. It’s also about the effort involved. Microservices make it easier to identify scaling bottlenecks and then resolve those bottlenecks at a per-microservice level.
Many popular tools are available. A variety of technologies in the big data world, including the open-source community, work well in a microservices architecture. Apache Hadoop, Apache Spark, NoSQL databases and many streaming analytics tools can be used for microservices. We are also proud to partner with Pivotal in this area.
它们带来更多输出。数据集常常以不同方式呈现给不同受众；微服务简化了为各类最终用户提取数据的方式。
更容易评估应用生命周期中的更新。包括机器学习在内的高级分析环境，需要对照新建模型来评估现有计算模型。微服务架构中的 A-B 测试和多变量测试让用户能够验证更新后的模型。
它们实现扩展。可扩展性不只是处理更大容量的能力，还涉及所需投入的精力。微服务更容易识别扩展瓶颈，并在单个微服务层面解决这些瓶颈。
有许多流行工具可用。大数据领域的各种技术，包括开源社区，都能在微服务架构中良好运作。Apache Hadoop、Apache Spark、NoSQL 数据库以及许多流式分析工具都可用于微服务。我们还很自豪能在这方面与 Pivotal 合作。
Let's take a second and examine each of those, but this time in light of prior art:
They promote big data best practices. Pipes-and-filters architectures have been a part of the software scene since the 70s, when Unixes promoted several ideas:
Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
They are relatively easy to build and maintain. See the Unix philosophy, above.
我们不妨花点时间逐一审视这些理由，但这次要结合已有的先例：
它们推动大数据最佳实践。管道-过滤器架构自 70 年代起就是软件领域的组成部分，当时 Unix 提倡了几条理念：
让每个程序只做好一件事。要做新工作，就重新构建，而不是通过添加新“功能”把旧程序复杂化。
预期每个程序的输出都会成为另一个未知程序的输入。不要在输出中塞入无关信息。避免严格要求列式或二进制的输入格式。不要坚持交互式输入。
它们相对容易构建和维护。参见上文的 Unix 哲学。
They enable higher-quality code. If focusing on one small part at a time helps improve quality, then see the Unix philosophy, above.
They simplify cross-team co-ordination. This one is interesting; it suggests that "service-oriented architectures (SOAs) ... typically involve heavyweight inter-process communications protocols"--like JSON over HTTP? Or is that taken to mean that all SOA requires SOAP, WSDL, XML Schema and the full collection of WS-* specifications? Ironically, nothing about a microservice in any way prevents it from using any of those "heavyweight" protocols, and some microservices are even suggsting the use of gRPC, a binary protocol that bears closer resemblance to IIOP, from CORBA, which was the "heavyweight protocol" predecessor to... SOAP, WSDL, XML Schema, and the full collection of WS-* specifications.
它们带来更高质量的代码。如果一次只专注一小部分有助于提高质量，那就参见上文的 Unix 哲学。
它们简化跨团队协作。这一点很有意思；它暗示“面向服务架构（SOA）……通常涉及重量级进程间通信协议”——是指基于 HTTP 的 JSON 吗？还是说所有 SOA 都必须用 SOAP、WSDL、XML Schema 以及全套 WS-* 规范？讽刺的是，微服务本身绝不阻止你使用任何这些“重量级”协议，而有些微服务甚至建议使用 gRPC——一种二进制协议，它与 CORBA 的 IIOP 更为相似，而 IIOP 正是……SOAP、WSDL、XML Schema 和全套 WS-* 规范的“重量级协议”前身。
They enable real-time processing. Real-time processing has actually been a "thing" for quite a while, and while many such systems use a pub-sub or "event bus" model to do it, it hardly requires microservices to do it.
They facilitate rapid growth. "Reuse the modular architecture"--do we even have a count of how many different things have all promoted "reuse" as a selling point? Languages certainly have done it (OOP, functional languages, procedural languages), libraries, frameworks.... One day I want to see something hyped that explicitly says "Screw reuse. We don't care about that."
它们支持实时处理。实时处理其实已经存在相当长一段时间了，虽然许多这类系统使用发布-订阅或“事件总线”模型来实现，但这根本不需要微服务。
它们促进快速增长。“复用模块化架构”——我们甚至数得清有多少不同的东西都把“复用”当作卖点吗？语言肯定这么做过（OOP、函数式语言、过程式语言），库、框架……总有一天，我想看到某个被炒作的东西明确说：“去他的复用。我们不在乎那个。”
They enable more outputs. "Data sets often are presented in different ways to different audiences"--that sounds a great deal like the Crystal Reports home page.
Easier to assess updates in the application life cycle. The need to "assess existing computational models against newly created models" for machine learning and advanced analytics environments... kinda sounds like a large pile of action words thrown together with little substance behind them.
它们带来更多输出。“数据集常常以不同方式呈现给不同受众”——这听起来非常像 Crystal Reports 的主页。
更容易评估应用生命周期中的更新。为了机器学习和高级分析环境，需要“对照新建模型来评估现有计算模型”……这听起来有点像把一大堆动作词堆在一起，背后却没什么实质内容。
They enable scale. How funny--the same was said of EJB, transactional middleware processing (a la Tuxedo), and mainframes.
Many popular tools are available. I don't think I have to really work hard to point out that tools have always been available for every major hype that's come through our industry--particularly after the hype has taken root for a while. Most readers won't even be old enough to remember CASE tools but maybe they'll remember UML.
它们实现扩展。多有趣——当年对 EJB、事务型中间件处理（类似于 Tuxedo）和大型机也是这么说的。
有许多流行工具可用。我想我不用费多大劲就能指出，我们这个行业出现的每一次重大炒作，都一直有工具可用——尤其是在炒作扎根一段时间之后。大多数读者甚至还没到能记得 CASE 工具的年纪，但也许他们记得 UML。
But the discerning reader will notice that there is a pretty common theme to about half of the points above--the idea of creating and maintaining small, independent "chunks" of code and data, versioned apart from one another, using common inputs and outputs to enable a larger integration of the system. It's almost as if...
At the heart of microservices, we find...
... modules.
Yup, the lowly "module", that core concept that has been at the heart of most programming languages since the 1970s. (Even earlier, though it was harder to do with older languages that didn't incorporate the module as a first-class core concept.) Call them "assemblies" on the CLR (C#, F#, Visual Basic, ...), "JARs" or "packages" on the JVM (Java, Kotlin, Clojure, Scala, Groovy, ...), or dynamically-link libraries from your favorite operating system (DLLs on Windows, sos or as on *nixes, and of course macOS has the "Frameworks" tucked away inside the /Library directories), but at a conceptual level, they're all modules. Each has a different internal format, but each serves the same basic purpose: an independently-built, -managed, -versioned, and -deployed unit of code that can be reused.
但眼光敏锐的读者会注意到，上面大约一半的理由都有一个共同主题——创建并维护小型、独立的代码和数据“块”，彼此独立版本化，使用共同的输入和输出，以实现更大的系统集成。这几乎就像……
在微服务的核心，我们会发现……
……模块。
没错，就是那个不起眼的“模块”，自 1970 年代以来大多数编程语言的核心概念。（更早也有，只是在不把模块作为一等核心概念的旧语言里更难做到。）在 CLR 上叫“程序集”（C#、F#、Visual Basic……），在 JVM 上叫“JAR”或“包”（Java、Kotlin、Clojure、Scala、Groovy……），或者你最喜欢的操作系统里的动态链接库（Windows 上的 DLL，*nix 上的 so 或 a，当然 macOS 还有藏在 /Library 目录里的“Frameworks”），但从概念层面看，它们都是模块。每个模块的内部格式不同，但都服务于同样的基本目的：一个可独立构建、管理、版本化和部署的代码单元，并且可以复用。
Consider this working definition of a module, quoted from one of Computer Science's foundational papers:
"A well-defined segmentation of the project effort ensures system modularity. Each task forms a separate, distinct program module. At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules. At checkout time the integrity of the module is tested independently; there are few scheduling problems in synchronizing the completion of several tasks before checkout can begin. Finally, the system is maintained in modular fashion; system errors and deficiencies can be traced to specific system modules, thus limiting the scope of detailed error searching."
This comes from David Parnas' seminal paper, "On the Criteria To Be Used in Decomposing Systems into Modules", written in 1971--over 50 years ago at the time of this writing. The well-defined "separate, distinct program modules" covers about half of the suggested benefits of microservices, and we've been able to do that for fifty years.
不妨看看计算机科学奠基论文之一给出的模块工作定义：
“对项目工作进行定义良好的切分，可以确保系统模块化。每项任务形成一个独立、清晰的程序模块。在实现时，每个模块及其输入和输出都定义良好，与其他系统模块的预期接口没有混淆。在检查时，模块的完整性被独立测试；在开始检查之前同步多个任务的完成，几乎没有调度问题。最后，系统以模块化方式维护；系统错误和缺陷可以追溯到特定的系统模块，从而限制详细错误搜索的范围。”
这段话出自 David Parnas 的开创性论文《On the Criteria To Be Used in Decomposing Systems into Modules》，写于 1971 年——截至本文写作已过去 50 多年。定义良好的“独立、清晰的程序模块”涵盖了微服务所建议好处的大约一半，而我们已经能做到这一点五十年了。
So why the hullabaloo over microservices?
Because microservices were really never about microservices, or services, or even distributed systems.
At the heart of microservices, we should find...
... organizational clarity.
那么，为什么微服务会引起这么大动静？
因为微服务从来就不是真正关于微服务、关于服务，甚至不是关于分布式系统。
在微服务的核心，我们应该发现……
……组织清晰度。
Amazon, one of the first companies to openly discuss the microservice concept, really wasn't trying to push the architectural principle as much as they were trying to push the idea of an independent development team whose blockers were few and far between. Waiting on the DBA team for schema changes? QA needs a build to test so they can find bugs? Or are we waiting on the infrastructure team to procure a server? Or the UX team to create a prototype for the presentation?
SCHHHLLLUURRRRRRRPPPPpppp...
That sound you hear is the development team aggregating ownership of any and all of those dependencies that could (and frequently would) block them from moving forward. It meant that the teams were a small microcosm of the average IT team's various parts (analysis, development, design, testing, data management, deployment, administration, and more). It did mean that now teams either had to be assembled from a variety of disparate skillsets, or else we had to require the complete set of skills in each team member (the so-called "Full Stack Developer"), which meant that hiring these folks became infinitely trickier. It also meant that now the team was responsible for its own production outages, meaning the team itself now has to be given on-call responsibilities (and the commensurate payroll and legal implications that go along with that). But, when all that was navigated, it meant that each team could build their artifact independently of one another, constrained by nothing other than time and the physics of how fast fingers can fly over a keyboard.
In theory, anyway.
亚马逊是最早公开讨论微服务概念的公司之一，它真正想推动的其实不是架构原则，而是一种独立开发团队的思路：团队的阻碍少之又少。还在等 DBA 团队改 schema？QA 需要一个构建版本来测试、找 bug？还是在等基础设施团队采购服务器？或者等 UX 团队为演示做原型？
SCHHHLLLUURRRRRRRPPPPpppp……
你听到的声音，是开发团队把所有可能（而且经常真的会）阻碍他们前进的依赖项的归属权都吸拢过来。这意味着团队成了普通 IT 团队各个部分（分析、开发、设计、测试、数据管理、部署、管理等等）的微缩版。这确实意味着，现在团队要么由多种不同技能的人拼装而成，要么我们就得要求每个团队成员具备全套技能（所谓的“全栈开发者”），这意味着招聘这些人变得无比棘手。这也意味着团队现在要为自己的生产故障负责，于是团队本身必须承担 on-call 职责（以及随之而来的薪酬和法律影响）。但是，当这一切都搞定之后，就意味着每个团队可以彼此独立地构建自己的产物，除了时间和手指在键盘上飞得有多快这一物理限制外，不受任何约束。
至少理论上是这样。
At the heart of microservices, we often find...
... the Fallacies of Distributed Computing.
For those not familiar with them, the Fallacies were first coined by Peter Deutsch in a presentation to his peers at Sun--back in the 80s. They reappeared in the 1994 seminal paper "A Note on Distributed Computing" by Ann Wolrath and Jim Waldo, and they both essentially say the same thing:
"Getting distributed systems right--performance, reliability, scalability, whatever "right" means--is hard." (loosely paraphrased)
When we decomposed the system into in-memory modules running on a single operating system node, the costs of passing data across process or library boundaries was pretty negligble, even fifty years ago. When passing that data across network lines, though--as most microservices do--adds five to seven orders of magnitude greater latency to the communication. That is not simply something we can "scale away" by adding more nodes to the network; that actually makes the problem worse.
Yes, some of that can be made less relevant by hosting the microservices on the same machine, usually by loading them into a cluster of virtual machines running containerized images of the independent microservice. (As in, using Docker Compose or Kubernetes to host a collection of Docker containers.) Doing so, however, adds latency between the virtual machine process boundaries (because we have to move data up and down the virtual networking stack, in accordance with the rules of the seven-layer model, even if some of those layers are being entirely emulated), and still creates the reliability issue of running on a single node.
在微服务的核心，我们经常发现……
……分布式计算的谬误。
不熟悉的人可以了解一下：这些谬误最早由 Peter Deutsch 在 80 年代向 Sun 的同事做的一次演讲中提出。它们又在 1994 年的开创性论文《A Note on Distributed Computing》中由 Ann Wolrath 和 Jim Waldo 重新提出，二者本质上说的是同一件事：
“把分布式系统做对——性能、可靠性、可扩展性，无论‘对’意味着什么——都很难。”（大意转述）
当我们把系统分解为运行在单个操作系统节点上的内存模块时，跨进程或库边界传递数据的成本即使放在五十年前也微不足道。然而，当数据跨网络线路传递时——大多数微服务正是如此——通信延迟会增加五到七个数量级。这不是我们通过向网络中添加更多节点就能“扩展掉”的问题；实际上，那会让问题更糟。
是的，如果把微服务托管在同一台机器上，通常是将它们加载到运行独立微服务容器镜像的虚拟机集群中（比如用 Docker Compose 或 Kubernetes 托管一组 Docker 容器），其中一些问题可以变得不那么重要。但这样做会在虚拟机进程边界之间增加延迟（因为我们必须按照七层模型的规则，让数据在虚拟网络栈上上下移动，即使其中某些层完全是模拟的），而且仍然会带来运行在单个节点上的可靠性问题。
What's worse, even as we start to wrestle with the Fallacies of Distributed Computing, we begin to run into a related, but separate, set of problems: The Fallacies of Enterprise Computing.
At the heart of microservices, we need...
... to start rethinking what we really need.
Do you need to decompose the problem into independent entities? You can do that by embracing standalone processes hosted in Docker containers, or you can do that by embracing standalone modules in an application server that obey a standardized API convention, or a variety of other options. This isn't a technical problem that requires abandoning anything that's already been built--it can be done using technologies from anywhere in the last twenty years, including servlets, ASP.NET, Ruby, Python, C++, maybe even shudder Perl. The key is to establish that common architectural backplane with well-understood integration and communication conventions, whatever you want or need it to be.
Do you need to reduce the dependencies your development team is facing? Then begin by looking at those dependencies and working with partners to determine which of them you can bring into the team's wheelhouse. If the organization doesn't want to officially break up the "skill-centric" ontology of its org chart (meaning you have a "database" group, a "infrastructure" group, and a "QA" group as peers to your "development" group), then work with the senior executives to at least allow for a "dotted-line" reporting structure, so there's individuals from each group that are now "matrixed" in on a single team. But, most importantly, make sure that team has a crystal-clear vision of what it is they're trying to build, and they can confidently describe the heart of their service/microservice/module to any random stranger walking by on the street. The key is to give the team the direction and goal, the autonomy to accomplish it, and the clarion call to get it done.
更糟的是，就在我们开始应对分布式计算的谬误时，又会遇到一组相关但独立的问题：企业计算的谬误。
在微服务的核心，我们需要……
……重新思考我们真正需要什么。
你需要把问题分解为独立实体吗？你可以采用托管在 Docker 容器中的独立进程，也可以采用应用服务器中遵循标准化 API 约定的独立模块，或者各种其他方案。这不是一个必须抛弃已有成果的技术问题——用过去二十年里的任何技术都能做到，包括 servlet、ASP.NET、Ruby、Python、C++，甚至可能令人颤抖的 Perl。关键在于建立那个共同的架构底板，配上一套易于理解的集成和通信约定，无论你想让它是什么、需要它是什么。
你需要减少开发团队面临的依赖吗？那就先审视这些依赖，与合作伙伴一起确定哪些可以纳入团队的能力范围。如果组织不想正式打破其组织架构图中“以技能为中心”的本体（也就是说，你的“开发”组旁边有同级的“数据库”组、“基础设施”组和“QA”组），那就与高管合作，至少允许“虚线”汇报结构，让每个组里都有人以“矩阵化”方式加入同一个团队。但最重要的是，确保这个团队对要构建什么有极其清晰的愿景，并且能自信地向街上随便走过的陌生人描述其服务/微服务/模块的核心。关键在于给团队方向和目标、实现目标的自主权，以及完成任务的明确号令。
It really boils down to these two things, which really, really, really have nothing to do with each other except tangentially.
Tags: predictions
归根结底就是这两件事，而它们除了勉强沾边之外，真的、真的、真的彼此无关。
标签： 预测