概览

我个人从业经历的技术架构演进，是从单机架构开始的，先后经历了单机、SOA、微服务，以及目前还没彻底摸清的云原生。若从我对技术演进的认知出发，把比单体更早的技术也包含进去，我觉得技术架构的演进，可以分为以下几个阶段：

1. 原始分布式 -> 单机

2. 单机 -> SOA

3. SOA -> 微服务

4. 成熟的微服务与云原生

1. 原始分布式 -> 单机

这个阶段的技术演进，我觉得根本上的一个重要原因是“摩尔定律”的影响。

分布式技术的很多理念和实现，其实在上世纪七八十年代就已形成，那时候主要以大型机为主，而且即便是大型机，算力也很有限，要想让计算机能发挥更大的能力，必然是按水平扩展的方式来增强，因此最初的分布式架构、rpc 的实现，很早就初步成型。

不过那个时期也正是“摩尔定律”最发光发热的时期，每 18 个月算力就能翻倍，这逐渐把计算机的主流由大型机转向小型机，且小型机的算力足够支撑业务的发展，由此很多之前需要借助分布式技术来实现的能力，在单机内就能搞定，这让单机架构慢慢兴起并逐渐成为主流。

单机架构相比于比分布式架构，简单有效，易于实施，因此应用非常广泛，时至今日也不乏应用场景。虽然在单机架构下，业务也得到了飞速发展，但只要算力的增长能满足业务的量级和业务的增长，单机架构就有应用场景。

2. 单机 -> SOA

这个阶段的技术演进，我觉得根本上的原因是，业务的进一步激增和“摩尔定律”的逐渐失效。

单机架构居功至伟，扩大了计算机能处理的业务边界范围，也逐渐让业务的量级逐渐超出单机算力能处理的极限，若要平衡算力和业务，让业务处于算力能处理的范围内，必然要对业务做分解和分发，让更多计算机分别处理一部分业务，然后再做整合，这让架构又开始从单机往分布式演进。

从单机到 SOA，我觉得是这个阶段里程碑意义的两点，如果在进一步细分，我觉得可以分为单机->单体，单机（单体）-> SOA 两个子阶段。

2.1 单机 -> 单体

我个人是把单体视为区别于单机的另一种架构的，所谓单机，就是把所有的技术实现，都放到同一台计算机上，而单体，是基于分层的业务架构的（如 MVC），只有同一层的核心业务，需要作为一个整体放到同一台计算机上，而相对独立的非核心业务或其他层级的业务，均可以放到其他计算机上。

这里之所以把单体单独摘出来，一方面，单体是单机的一种进化，现在依然应用广泛，另一方面，单体，也是下一代的微服务架构演进的发力点之一，值得在技术演进中提一笔。

单体的主导思想还是单机，且已经有一定的工作分解在其架构中了，但若业务的复杂度更进一步，它依然不能好好的应对，需要有更进一步的里程碑式架构方案来解决问题

2.2 单机（单体）-> SOA

从单机走向分布式的过程中，单体盛行，C/S 模式、B/S 模式等均是实际应用中的解决方案，但只有 SOA 的提出，才形成了走向分布式里程碑的解决方案。

SOA 既是一种技术架构，也是一种架构思想，它提出面向服务做架构设计，这兼容单体、C/S、B/S 等实际生产中应用的模式，也意味着系统的功能模块，可以拆分为不同的服务，SOA 下支撑多种服务，因此很容易被接受和推广使用。

另外，除了业务特别复杂让单机/单体架构的系统不能很好的扩展和维护外，随着技术的发展，业务的普及和推广，（异构）系统的集成也日益成为业务发展的必然需求，这在单机/单体架构下很难开展，而 SOA 架构能迎刃而解。

由此，随着业务的发展，SOA 日益盛行。

3. SOA -> 微服务

SOA，既是一种技术架构，也为业务抛出了一个“面向服务”的概念，因此，在业务视角下，微服务可以看作是 SOA 的一个子集或一种演化，但从技术视角看，SOA 和微服务的底层技术是不相同的，因此在技术演进上来讲，微服务是区别于 SOA 的另一种架构，也是能比 SOA 更好的应对业务更近一步发展的架构。

SOA 作为一种架构思想，虽然在业务视角上看似解决了业务发展中的很多问题，但在技术层面，实际落地时依然有些问题不好解决：

1. SOA 中的每个服务，可能还是单机或单体服务，服务的可扩展性和可维护性良莠不齐

2. 服务间的通信，严重依赖总线，因此总线作为 SOA 核心基础设施，特别复杂

3. 总线通常是 SOA 中的单点，而总线又是核心，这进一步增加了总线的技术复杂度

SOA 盛行的时代，业务量级上亿的系统还是凤毛麟角，以我对 SOA 有限的认识看，让 SOA 去支撑亿级的系统也比较困难。因此不论是面向解决 SOA 中的技术痛点，还是应对后来的业务量级进一步发展，技术架构必然会走向下一步的技术演进。

微服务就是取代 SOA 的下一代技术，它对 SOA 做了进一步的拆解：

1. SOA 中的服务，可以进一步拆分为更小的颗粒度

2. 服务之间可以直接通信，不再依赖总线

3. 取消总线，拆解总线，取而代之的是一系列微服务基础设施，如服务注册、发现、限流、监控等

微服务不仅解决了 SOA 的痛点，也能把面向对象的思想融于其设计，因此单机/单体转微服务也很方便。

微服务是 2012～2014 年间提出和兴起的，这时分布式的各种理论体系基本成熟，虚拟化技术更加成熟易用，软硬件基础设施与生态进一步完善/完备，这都为微服务的兴起奠定了基础。

由此，微服务一经提出，迅速盛行，蓬勃发展至今。

4. 成熟的微服务与云原生的雏形

微服务发展至今，其理论、架构和生态已经基本成熟和稳定，微服务的完善过程中，也逐步催生了云原生相关技术，目前云原生初步成型，以我目前对云原生有限的认识看，云原生相当于微服务的另一种实现形式，其后续的发展演化，可能会让技术架构演化之下一阶段，姑且称之为里程碑意义的云原生架构，目前云原生仅是雏形，故暂且把成熟的微服务与云原生的雏形作为统一技术演进阶段。

4.1 成熟的微服务

微服务架构现在是成熟的技术架构，也是能够应对亿级业务规模强大架构，但它同时也是一套特别复杂的架构，它不是银弹，面向不同的业务量级和业务复杂度，各类技术架构依然存在有效的应用空间。

当前成熟火热的微服务架构，后续会单独总结梳理，本节结合我认为当前微服务架构设计和开发中可能存在陷阱，从另一个角度来描述一下对微服务的认识。

现在成熟的微服务，虽然是建立在完善的微服务基础设施之上，但微服务一直是一个上手门槛不高，精通吃透却很难的架构体系，这是选型微服务架构时的一个陷阱，开发者有可能会低估微服务的难度。一方面，微服务架构本质上是降低了内部复杂度，增加了外部复杂度，微服务如何拆分，微服务间如何协作很考验架构师的取舍能力，我们也一不小心就聚焦于它对内部复杂度降低的程度，忽略其对外部复杂度增加的程度；另一方面，微服务对基础设施的依赖，高并发、高可用、可扩展、安全性等技术要求，带来的分布式情况下的分工协作、并发控制、幂等设计、事务处理、事务补偿等实现逻辑，服务限流、降级、监控、追踪等带来的新复杂度，都可能会侵入式的改变原有业务逻辑，这些都是微服务架构设计和实现中的难点，也是可能会被乐观低估的点。

我认为微服务架构的有效应用，需要架构师的重度参与，而这点却可能会忽视。单机/单体架构，技术专家就能很好的承担研发工作；其他分布式架构，由于在缺失架构师参与的情况下，可能从一开始就无法很好的开展工作，故架构师的作用不会忽视；而微服务架构，由于在业务早期上手容易，没有架构师也可能会有效开展，但随着业务复杂度和量级的发展，没有架构师的把控可能会让系统开发变得越来越吃力，另外开发者可能被微服务的潮流裹挟，在架构设计未经充分评估权衡的情况下，直接无脑错误选型微服务；这些都是微服务开发中另一个潜在陷阱带来的问题。

4.2 云原生的雏形

微服务的逻辑需要对应的成熟基础设施，当微服务的基础设施不在应用层的微服务框架提供，而是转向基础设施层提供时，这种微服务，就成了云原生微服务。

当云原生相关的技术和生态完全成熟后，微服务技术框架中面向微服务基础设施的复杂度，会转移到云原生基础设施上去，且复杂度转移后，应用层微服务的开发更简单，基础设施上的复杂度，对微服务业务的开发几乎是无感的，性能也会有一定程度的增强，那时，我们可以把云原生作为技术架构从微服务进一步演进的下一代技术，而当前，云原生的技术生态尚未成熟，技术设施上的复杂度依然暴露在微服务开发者的视野下，故暂时把云原生技术视为实现微服务架构的另一种方式。

5. 总结

1. 技术的发展，也是分久必合，合久必分的，我觉得这期间一个不变的主线，是对变化的封装和对复杂度的转移。

2. 当算力强于业务发展时，将复杂度封装和转移到单机中，单机内部复杂度增加，而外部应用的复杂度降低，推进了技术的演进和业务的发展；

3. 当算力的增长无法让单机处理激增的业务时，会对业务做工作分解和分配，把原本在内部的复杂度又转移到外部，让算力得以应对分解后到业务；

4. 以往技术的发展，是在封装和转移复杂度，带来了这几十年的技术架构演进，以后的技术，将会带来封装和转移复杂度的新方式，从而推进技术架构未来的演进。

5. 复杂度不会消失，只能被转移，外部复杂度的降低必然带来内部复杂度的提升，反之亦然。每一代的技术架构，无非是找到了内外部复杂度变化的平衡点，并提供了技术落地实现和维护使用行之有效且提高效率的手段。

6. 技术和业务的发展相辅相成，技术的发展带来新的生产力，扩大了业务的量级和边界，带来新的业务模式，业务的发展和创新也倒逼技术的革新和进步；技术架构的演进与业务发展密不可分

7. 正是由于复杂度不会降低，只会转移，新旧技术间是有藕断丝连的关系的，搞清楚经典的技术理论，也利于迅速掌握新技术的本质（如单机多核时代的并发理论，同样可以借鉴到微服务的并发与同步中）

What's More

欢迎查阅本文的微信公众号链接和个人博客链接