1.1 原始分布式时代
因为单台计算机硬件的算力有限，所以使用多台计算机共同协作来完成一个计算任务。分布式系统有一个重要的原则，即分布式环境中的服务调用、资源访问、数据存储等操作尽可能透明化、简单化，从而使开发人员不用过去关注他们访问的方法或者其他资源是位于本地还是远程。
远程调用带来的问题包括，服务发现，负载均衡，服务熔断、隔离、降级，序列化协议，传输协议，认证、授权，网络安全，分布式数据一致性等。
1.2 单体系统时代
单体架构有适合自己的应用场景，单体性能的不足必须在软件的性能需求超过了单机性能的极限，开发团队的规模明显超过了“2 Pizza Team”的前提下，才适合引入分布式架构。
一部分人说单体架构的缺点是不可拆分，难以扩展，因此不能支撑越来越大的软件规模。这种想法看似是对的，其实是有失偏颇的。
从纵向角度来看，单体架构都会采用分层架构的设计，对代码进行纵向层次的划分，包括微服务也是一样的。对于“业务代码模块”的可拆分和扩展，单体架构并没有丝毫弱势，而且单体架构的更容易开发，部署，测试和运维，使得开发更便捷。
从横向角度来看，通过负载均衡，部署包含多个服务节点的集群，也是非常常见的部署模式。
在单体架构中，所有代码都运行在同一个进程内，所有的模块，方法的调用都无须考虑网络分区、对象复制这些麻烦的事和性能损失，而且在进程内的调用比较简单、高效。但是当一部分代码出现问题时，所造成的影响也是全局性的，难以隔离的。如果影响到了某些公共资源，比如数据库连接池，还可能会影响到集群中的其他机器。在运维方面，单体架构对程序进行升级，修改时往往还需要制定专门的停机更新计划，做灰度发布，A/B测试也更复杂。
单体架构和微服务架构都有各自适用的场景。当系统规模小的时候，单体架构有优势，当系统规模大的时候，分布式系统有优势。当系统比较大时，微服务可以体现出隔离能力，技术栈异构，动态更新的优势。然而战术层面再优秀，也难以弥补战略层面的不足。当系统越来越大时，交付一个可靠的单体系统就变得越来越困难。随着软件架构的演进，构建可靠系统的挂念从“追求尽量不出错”到正视“出错是必然”的转变，才是微服务架构得以挑战并逐步取代单体架构的底气所在。
1.3 SOA时代
软件架构来到SOA时代，其包含的许多概念和思想都能在今天的微服务中找到。比如服务之间的高内聚低耦合，注册发现，隔离，编排等。SOA思想也有指定具体技术标准的组织Open CSA，明确采用SOAP作为远程调用协议，依靠SOAP协议族来完成服务的发布、发现和治理，利用企业服务总线ESB的消息管道来实现各个子系统之间的交互，使用服务数据对象SDO来访问和表示数据，使用服务总线架构SCA来定义服务封装的形式和服务运行的容器等等。如果仅从技术可行性来考虑的话，SOA可以算是已经成功解决了分布式环境中出现的主要技术问题。
SOA在十年前风行一时，但是由于严格定义带来的复杂性，使得只有专业人员才能够开发，它可以实现多个异构大型系统之间的复杂集成交互，却很难作为一种具有广泛普适性的软件架构风格来推广。分布式服务的设计宗旨就是：开发人员不必关心服务是远程还是本地，都能够透明地调用服务或者访问资源。
1.4 微服务时代
微服务是一种通过小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个微服务可以采用不同的变成语言、不同的数据存储技术，运行在不同的进程中。服务采用轻量级的通信机制和自动化的部署机制实现通信和运维。文中列出了微服务的9个核心特征和简单解释
-
围绕业务能力构建
产品架构是根据团队来演化的
-
分散治理
服务对应的开发团队，对服务运行的质量负责
-
通过服务来实现独立自治的组件
通过服务而不是类库来构建组件。尽管远程服务有更高昂的的调用成本，但是为组件带来自治与隔离能力的必要代价
-
产品化思维
避免把软件研发看做要完成某种功能，而是视作一种持续改进、提升的过程
-
数据去中心化
提倡数据按领域分散管理，同一个数据实体在不同的服务的视角里，它的抽象形态往往是不同的，使用中心化存储，所有领域都必须修改和映射到同一个实体中，这很可能使服务之间互相影响而失去独立性
-
强终端弱管道
如果服务需要额外的通信能力，则应该在服务的终端上解决，而不是在通信管道上处理，所以RESTful风格的通信能力在微服务中会是更合适的选择
-
容错性设计
不再虚幻地追求服务永远稳定，而是接受服务总会出错的现实，必须有容错的设计。不然系统很容易被一两个服务崩溃所带来的的雪崩效应淹没。可靠的系统完全可能由会出错的服务组成，这是微服务最大的价值
-
演进式设计
承认服务会被淘汰，一个设计良好的服务，应该是能够报废的，而不是期望得到长存永生
- 基础设施自动化
如CI/CD的长足发展，显著减少了构建，发布，运维工作的复杂性，使得微服务团队更加依赖于基础设施的自动化
1.5 后微服务时代 或者称为云原生时代，因为k8s成为容器战争的胜利者，但是它却没有完美解决全部分布式的问题。仅从功能上看，单纯的k8s反倒不如SpringCloud，因为有一些问题处于应用系统与基础设施的边缘，使得很难完全在基础设施层面中精细化地处理。为了解决这一类问题，引入了服务网格，指的是自动在服务容器中注入一个通信代理服务器，这个代理除了实现正常的服务间通信外，还接收来自控制器的命令，根据控制平面中的配置，对数据平面通信的内容进行分析处理，以实现熔断，认证，度量，监控，负载均衡等各种附加功能。实现了既不用在应用层面中加入额外的处理代码，也提供了几乎不亚于程序代码的精细管理能力。
1.6 无服务时代
绝对意义上的无限性能是不存在的，但是在云计算落地已有十余年的今天，相对意义上的无限性能已经成为现实。无服务现在还没有一个特别权威的官方定义，无服务以简单为主要卖点，只涉及两块内容，后端设施和函数。
后端设施是指数据库、消息队列、日志、存储等这类用于支撑业务逻辑运行，但是本身无业务含义的组件。这些设施都运行在云中，在无服务中将它们称为“后端即服务”。
函数是指业务逻辑代码，也可以类比为编程语言中的函数，在无服务中称为“函数即服务”。 无服务的愿景是让开发者只需要纯粹地关注业务，不需要考虑技术组件，后端的技术组件都是现成的，可以直接取用。不需要考虑部署，不需要考虑算力，不需要操心运维。但是无服务要按资源使用量来计费，所以函数不会常驻服务器，冷启动的性能比较差。
谈架构演进的历史，是为了理解每种架构出现的意义与淘汰的原因，为的是更好地解决今天的现实问题，寻找出未来架构演进的发展道路。
