Understanding Distributed Systems: Core Concepts, Misconceptions, and Design Principles

When asked to define a “distributed system”, many people immediately think of concrete artifacts such as SOA, ESB, or micro‑services, but equating these with distributed systems is a misconception.

Service‑oriented design is akin to grouping similar job roles into a department to improve reuse; its essence is “divide‑and‑conquer”. The key is how to split a system, not which service‑oriented model is chosen.

High cohesion and low coupling are crucial during decomposition because they reduce the complexity of component collaboration. The article illustrates this with an organizational analogy: splitting a 10,000‑person company into 20 functional departments (500 people each) creates high cohesion and low coupling when work flows linearly, but frequent cross‑department interactions increase coupling.

In practice, many developers mistakenly equate middleware (MQ, RPC, DAL) with distributed systems. Middleware merely standardizes communication (asynchronous messaging, real‑time RPC, data‑access abstraction) and reduces technical complexity, but a distributed system is more than the middleware it uses.

Understanding what is stable versus variable is essential. The article provides a code‑like example of “serving rice” to show how the stable part (the method) can be abstracted similarly to middleware, highlighting the need to identify and standardize the invariant aspects of a system.

Even a simple “single program + single database” setup is a distributed system because the application process and the database process run separately and must cooperate, much like a two‑person three‑leg race. Issues such as logs showing success while the database remains unchanged illustrate classic distributed‑system challenges.

According to Wikipedia, a distributed system consists of components on different networked computers that communicate via messages to achieve a common goal. This aligns with the “divide‑and‑conquer” principle: large computational tasks are split across many machines and the results merged.

The article concludes that recognizing the internal mechanics of a system outweighs superficial appearances; any system requiring multiple processes to deliver a complete function qualifies as a distributed system. Mastering the underlying theory, rather than merely the tools, is essential for building robust distributed architectures.

碗 继承基类的子类：大碗、小碗、汤碗基类：

勺子 继承基类的子类：铁勺、陶瓷勺、塑料勺

function 盛饭（参数 人，参数 碗，参数 勺子）{

do 人拿起碗

do 人拿起勺子

do 人用勺子舀起饭

do 人把勺子放到碗的上方并倒下

}

...