1977年的时候，研制成功了第一台微型机“DJS050”。
上个世纪80年代，计算机开始从大型机为主向微型机为主的蜕变。计算机也从科研实验机构走向了家庭个人。当时微型计算机的运算处理能力相对局促，内存地址空间只有128KB,为了突破这种硬件的制约，一些高校，研究机构，和厂商开始探索使用多台设备来协同工作支撑同一套软件系统运行。
这是分布式架构最原始的探索，比我曾经以为的早很多。
正如计算机本身的发展就是多面性的,一方面会建造更大型,算力更强的的计算机,一方面又会设计打造更小的微型机.很多人也试图突破冯诺依曼的架构,创造出新模式的计算机.
软件系统根植于计算机,它的发展也是呈现了几个方向.
单体架构系统单体架构相对于分布式架构,在软件架构的发展历程中,最早出现,应用范围广,使用人数多.相对比较简单.特别是对于小型系统而言,单台机器就足以支撑系统的良好运行，单体架构易于开发、易于测试、易于部署，且由于系统中各个功能、模块、方法的调用过程都是进程内调用，不会发生进程间通信，因此也是运行效率最高的一种架构风格.
单体架构也有其自身的局限性.一个软件系统的规模越来越庞大的话,即使我们按照技术、功能、职责等维度，将软件拆分为各种模块，以便重用和管理代码,它的体量也增加了维护管理的难度.单台计算机的性能不足以支撑软件运行的时候,我们也可以选择部署多份单体系统的副本,通过负载均衡器达到分摊流量压力的效果.单体架构下，所有的系统都运行在一个进程中,即使是两个互没有联系的系统。当系统规模小的时候，单体是优势，但当系统规模大，或程序需要修改的时候，其部署的成本、技术升级的迁移成本都会变得更为昂贵。
分布式架构
分布式架构对大型的单体系统进行拆分，让每一个子系统都能独立地部署、运行、更新.
在分布式架构的探索中,开发者们也进行了很多的尝试.
烟囱式架构（Information Silo Architecture）：这种架构的系统也被称为孤岛式信息系统或者烟囱式信息系统。主要是通过将系统中完全不相干的子系统进行拆分,各种使用独立的数据库和服务器进行部署运行.它的前提是完全的信息孤岛,与其它其它不发生任何的交互,这样拆分出来的老死不相往来的系统不贴合现在各种系统融合交互的发展.微内核架构（Microkernel Architecture）：微内核架构也被称为插件式架构（Plug-in Architecture）。在这种架构中,将一些公共的主数据提炼出来,作为系统的核心,而具体的业务以插件的形式存在.这样业务就是可扩展的,灵活的.比如系统的使用人员,权限是核心数据,其它业务都会涉及到操作人员的权限问题.但插件式架构中,插件都是不会直接交互的,都是各自与系统核心交互,这也不大符合一些需要插件相互交互的场景.事件驱动架构（Event-Driven Architecture）：为了让插件式的子系统互相通信，事件驱动通过在子系统之间建立一套事件队列管道，系统通过将与其它系统交互的消息将以事件的形式发送至管道中，各个子系统从管道里获取自己需要处理的事件消息.消息的发布和处理通过事件队列管道解耦,各个系统相互独立,又能相互操作.面向服务的架构（Service Oriented Architecture，SOA）: 2006 年成立了 OSOA 联盟,2007 年OSOA 联合 OASIS 共同新成立了的Open CSA组织,成为SOA 的官方管理机构。SOA有清晰软件设计的指导原则，譬如服务的封装性、自治、松耦合、可重用、可组合、无状态等；明确了采用 SOAP 作为远程调用的协议，依靠 SOAP 协议族来完成服务的发布、发现和治理；利用一个被称为企业服务总线的消息管道来实现各个子系统之间的通信交互;使用服务数据对象来访问和表示数据，使用服务组件架构来定义服务封装的形式和服务运行的容器，等等。这一整套成体系可以互相精密协作的技术组件支持下，SOA 可以算是成功地解决了分布式环境下出现的主要技术问题。微服务架构（Microservices）: 它是由 Peter Rodgers 博士在 2005 年度的云计算博览会上提出的.微服务架构是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。微服务追求更加自由的架构风格，摒弃了几乎所有 SOA 里可以抛弃的约束和规定，提倡以“实践标准”代替“规范标准”。但是没有了SOA复杂的统一规范和约束，以前 SOA 所解决的那些分布式服务的问题又都重新出现，服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展、传输通信、事务处理等问题，在微服务中不再会有统一的解决方案.后微服务时代/云原生（Cloud Native）:从软件层面独力应对微服务架构问题，发展到软、硬一体，合力应对架构问题的时代。容器化技术的发展,特别是Kubernetes在容器编排管理中占据的统治地位.它提供的基础设施层面的解决方案,如弹性伸缩,服务发现,配置中心,服务网关,负载均衡,服务安全等,那些与业务无关的技术性问题便有可能从软件层面剥离，解决于硬件基础设施之内，让软件得以只专注业务.Kubernetes虚拟化的基础设施从单个服务的容器扩展至由多个容器构成的服务集群、通信网络和存储设施时，软件与硬件的界限便已经模糊.服务网格（Service Mesh）:服务网格的边车代理模式由系统自动在服务容器中注入一个通信代理服务器，在应用毫无感知的情况下，接管应用所有对外通信。这个代理除了实现正常的服务间通信外，还接收来自控制器的指令，根据控制平面中的配置，对数据平面通信的内容进行分析处理，以实现熔断、认证、度量、监控、负载均衡等各种附加功能。这样便实现了既不需要在应用层面加入额外的处理代码，也提供了精细管理能力。它对应用是透明的，不需要改动任何软件代码就可以实现服务治理,将业务与技术完全分离.无服务架构无服务架构得益于云计算的发展,如果单台服务器的性能是无限的, 对软件研发而言，不做分布式无疑是最简单的.尽管绝对意义上的无限性能是不存在的，但在云计算落地十多年的情况下，相对意义的无限性能已经成为了现实.无服务的愿景是让开发者只关注于业务，不需要考虑技术组件,系统部署，服务器算力，维护系统持续平稳运行等。它只涉及两块内容：后端设施和函数。
后端设施是指数据库、消息队列、日志、存储，等等这一类用于支撑业务逻辑运行，但本身无业务含义的技术组件，这些后端设施都运行在云中，无服务中称其为“后端即服务”（Backend as a Service，BaaS）。函数是指业务逻辑代码，接近于程序编码角度的函数，运行在云端.无服务中称其为“函数即服务”（Function as a Service，FaaS）。
