1.1 原始分布式出现的原因
可能与大多数人的认知有些差异，“使用多个独立的分布式服务共同构建一个更大系统”的设想与实际尝试，其实比大家所了解的大型单体系统出现的时间更早。
在20世纪70年代末期到80年代初，计算机科学经历了从以大型机为主向以微型机为主的蜕变，计算机硬件有限的运算处理能力，已经影响到了单台计算机上信息系统软件能够达到的最大规模。
为突破硬件算力的限制，高校、研究机构、软硬件厂商开始分头探索，寻找使用多台计算机共同协作来支撑同一套软件系统的可行方案。
这一阶段是对分布式框架的最原始的探索，虽然不能一蹴而就地解决分布式的难题，但是这个阶段的探索称得上成绩斐然。
为避免UNIX系统的版本战争在分布式领域中重演，负责定制UNIX系统技术标准的“开放软件基金会”邀请了当时业界主流的计算机厂商一起参与，共同制定了名为“分布式运算环境”（Distributed Computing Environment，DCE）的分布式技术。
DCE包含一套相对完整的分布式服务组件规范与参考实现：
源自NCA的远程服务调用规范（Remote Procedure Call，RPC）
通用TCP/IP协议的远程服务标准
源自AFS的分布式文件系统（Distributed File System，DFS）规范
源自kerberos的服务认证规范
额外知识
UNIX的分布式设计哲学
保持接口与实现的简单性，比系统的任何其他属性，包括准确性、一致性和完整性，都来得更加重要。
——Richard P.Gabriel，The Rise of Worse is Better，1991
1.2 原始分布式设计思想与问题
由于OSF本身的UNIX背景，当时对这些技术的研究都带着浓厚的UNIX设计风格，有一个预设的重要原则是要使用分布式环境中的服务调用、资源访问、数据存储等操作尽可能透明化、简单化，对于开发人员来说，不关注他们是在本地或者远程。
尽管“调用远程方法”和“调用本地方法”只有两字只差，但若要兼顾简单、透明、性能、正确、鲁棒、一致等特点，两者的复杂度就完全不可同日而语。
网络环境下的新问题如下：
远程服务在哪里（服务发现）
有多少个（负载均衡）
超时或者服务出错怎么办？网络出现分区怎么办？（熔断、降级、隔离）
方法的参数与返回结果表示（序列化协议）
信息如何传输（传输协议）
服务权限如何管理（认证、授权）
如何保证通信安全（网络完全层）
如何令调用不同机器的服务返回形同的结果（分布式数据一致性）
上面的大部分问题，DCE构建了大量的分布式基础组件和协议，而且真的尽力做到了相对“透明”，譬如在DFS上访问呢文件，如果不考虑性能差异，那么与本地没有什么不同。
可是，一旦考虑性能差异，那么远程和本地的鸿沟是无比深刻的，完全不可调和。开发一个良好运作的分布式应用，需要极高的编程技巧和各方面的专业知识去支撑。解决问题所付出的代价已远远超过了分布式所取得的收益。
原始分布式时代的教训
某个功能能够进行分布式，并不意味着它应该进行分布式，强行追求透明的分布式操作，只会自寻苦果。
——Kyle Brown，IBM Fellow，Beyond Buzzwords:A Brief History of
Microservices Patterns，2016
1.3 后续发展
现在，摆在计算机科学面前有两条通往更大规模软件系统的道路：一条是尽快提升单机的处理能力；另一条是找到更完美的、解决如何构建分布式系统的解决方案。
20世纪80年代正式摩尔定律开始稳定发挥作用的黄金时期，微型计算机的性能以每两年增长一倍的惊人速度提升，硬件算力束缚软件规模的链条很快变得松动，信息系统进入单体时代，且在很长的一段时间内，单体都将是软件架构的绝对主流。
尽管如此，对于另外一条路的探索也从未中断。在三十多年后的21世纪10年代，随着分布式架构逐渐成熟、完善，并取代代替成为大型软件的主流架构风格以后，这个美好的愿景将会重新被开发者拾起。