1、原始分布式时代

一直以来，我可能和大多数的人认知一样，认为我们的服务架构的源头是单体架构，其实不然，早在单体系统盛行之前，我们的前辈们就已经探索过使用多个独立的分布式服务共同完成一个大型的系统的实现方案。

众所周知，计算机的伊始是一个庞然大物，大概需要一整间屋子才可以容得下它那巨大的身躯。后来到了20世纪70年代末，计算机终于被聪明的科学家们设计再设计，摇身一变成了微型机，可以摆放在桌子上的那种。可这时候的微型计算机仍然属于它的时代的婴儿期，它没有我们想象中的高速的运算能力，它通常只有16位寻址能力、不足5MHz的时钟频率和128KB的内存空间，这种有限的运算处理能力直接限制住了单台计算机上可以运行的系统的规模，根本不利于我们来开发出一个理想的业务系统。

为了解决单个计算机处理能力有限的问题，聪明的科学家们想出了一个分而治之的好方法，一台咱不够用咱就搞两台，两台不够用咱搞10台，大问题拆解成小问题，大系统拆解成小系统让他们互相配合么，这不就解决了。想法确实不错只可惜出现的时代不对，我就想说一句：泰勒公式你找一个婴儿推理不出来，那找10个婴儿让他们互相商量商量就能推导出来了？

前辈们从来不只是说说而已，搞分布式那可是真的搞，于是早期的IT泰山北斗们开始浩浩荡荡的干起来了。大家一块制定“分布式运算环境”(DCE)的分布式技术体系,包含了一些远程调用规范、分布式文件系统、服务认证规范、时间服务及明明目录服务等等，甚至如今我们IT行业最熟悉不过的UUID也是在DCE中发明出来的，可以说DCE是现代分布式的一个鼻祖。

搞分布式自然少不了远程调用，可是对于当时的计算机硬件水平来讲，一旦加上远程两字，那执行时间是呈几何式的倍数增长，效率也大打折扣，况且对于服务的一些发现、负载均衡、服务熔断隔离降级等问题都没有一个十分完善的解决方案，就像我提到的那样，我们的微型计算机伊始就像一个婴儿一样，它太弱小了，弱小到根本没有足够的能力支持它和其他的计算机很好的去配合。至于如何去构建大规模的软件系统，要么就是尽快提升单机的处理能力，要么就是找到一条更完美的解决构建分布式系统的方案。

探索从未停止，但是原始的分布式时代高歌几年却终究没有盛行起来。

2、单体系统时代

单体架构算是大家最熟悉的一种架构了吧，基本每个开发者在学习时，都会去实践的一种架构。仔细想来，我从工作到现在还真没搞过单纯的单体架构，开始两年整的SOA，这两年一直是微服务。不过抛开整个大型系统来讲，单纯的看微服务架构中的某个服务，这也可以称得上是一个增强版的单体架构吧，只不过多了些服务注册了、feign远程调用了、包的结构设计更加趋于现在风格，主体业务代码的编写感知上和单体系统并无很多差别。当然放在整体系统来讲，那差异确实大了，单体系统将所有的模块功能都放在这个一个服务里，耦合度比较高，而微服务却拆分出来了，每个模块的职责比较明确，每个模块自成一个服务，很好的诠释了弱耦合、高内聚的概念。

自从20世纪80年代后，摩尔定律开始稳定发挥作用，计算机的性能以每两年一倍的惊人速度提升，我们的信息还没有像今天一样呈爆炸式增长，也没有那么多如今的各种高流量高并发的大规模场景，单台服务器或者少量几台服务器足可以支撑起大型信息系统的运作，于是单体系统时代来了，它足足占据主流地位了30年，放在如今很多小公司小系统也不乏有很多使用单体架构的。

单体系统到底是什么？从整体概念来看，他无非就是一个人也可以活得像一支队伍，好比如今我们的电商系统，可能大家都选择将用户模块、订单模块、支付模块、商品模块等等拆到不同服务中去运行，各司其职，有用得到对方的去调用一下，但是单体系统不会这样干，它就喜欢独掌大权的感觉，上文所述的众多功能它全自己一个人来搞定，有我一台服务就够了，绝对不会像其他服务通信求救，要是其中某个功能出了问题，咱大伙一块全下线；从架构划分上，单体架构内部的管理也是有模有样的，像我们最熟悉的MVC架构、SSM组合拳，通常不就是划分为了Controller表示层、Service业务层、Mapper持久层、DataBase数据库层。它的问题排查与运维成本通常也比我们如今盛行的微服务小很多，毕竟就一个服务在那，出了问题很明显就是它的错。

虽然说单体架构有自己的局限性，但不可否认我们如今新兴的所有架构都是在它的基础上演变来的。

3、SOA时代

关于SOA架构，坦白讲，这是我最没信心讲明白的一个架构了，因为从这几年的经历来讲，总感觉他没有一个很系统的架构模式的定义，说他是单体但是他已经存在多个服务属于分布式了，说他是微服务总感觉还差点意思，没有划分那么微小的粒度，虽说我工作前两年时同事告诉我咱使用的是SOA架构，但事实上，我当时对架构二字没有那么大的感知，能开发能写代码不就行了，接下里我就谈下我的一些不成文的浅陋认知，假设不对的地方还请多多包涵，批评指出。

SOA其实就是面向服务的架构，它对于服务的封装性、自治性、松耦合、可重用性有清晰的指导规则，它要求每个服务更具体更系统，与其说他是一套架构，倒不如说SOA是一套思想，每个公司可以根据自己的业务场景，按照它的指导思想去开发属于自己的系统架构，在这里我想谈两种架构的设计方式，大家也可以评估下是否可以归为SOA架构的范畴。

第一种大概是我19年-21年一直在经历的一种架构模式，开发技术就是SpringBoot + SpringData JPA，服务划分大概分为了基础服务、业务系统服务、定时服务三个服务，基础服务大概就是涵盖了一个系统最基础的那些功能模块：权限、角色、用户、审批流等等，每个功能模块用分包的方法区分开；而业务系统服务则是包含了各种业务性的功能，功能模块还是蛮多的，这里为了保密也就不展开说了，当时每个功能模块的区分方式一样也是分包路径的处理的；定时服务也是将所有的job加到这个服务里来开发。然后当时整个项目当时是没有注册中心的，也没有网关，也没有配置中心，服务之间的调用的通过feign-url的方式进行，比较优秀的一点它还引用了seata做了分布式事务的管理，每个服务有自己的DB，可以说这个系统确实是一个分布式的系统了，但是归为微服务还是欠缺点火候的，毕竟那些众多的业务模块并没有单独的划分出来自成一个服务，一个的功能模块出问题其余的也多少受影响的，不过也确确实实的算是面向服务开发了，所以将它归为SOA的范畴我觉得也是有些道理的。

第二种呢是我平时看一些学习视频提到的,它是一个标准的垂直划分的架构，自上而下分别拆分为了应用层、业务服务层、基础业务层、基础服务层、存储层。应用层也叫作接入层，只负责接收来自于用户的请求，不会直接访问DB，通过请求下游服务的接口来处理数据；业务服务层主要是用于处理各种业务场景，比如招聘网站的话就是处理一些职位搜索，简历投递一类的业务；而基础业务层则是处理一些系统最基础的核心功能，像招聘网站的职位管理、简历管理、可以为上游的业务服务层提供一些api的支持；基础服务层则是一些业务无关的模块，用于管理一些消息推送、附件解析、定时任务，这个服务的特点则是请求量大、逻辑简单、功能独立；而存储层则就是一些mysql、mongodb、Es一类的。整个系统呢引用了Dubbo及zookeeper来完成服务的治理的。

其实从服务拆分来看，第二种比起第一种来讲只是把controller应用层单独拆出了一个服务，其余的拆分手法还是蛮像的。从技术来看，第一种不含注册中心，而第二种却使用了zookeeper来充当了注册中心。二者有共性也有差异，但总归来想，都是往拆分服务的方向看齐，确实比起单体架构发生了质的改变。

4、微服务时代

微服务大概是目前正在流行的一种服务架构了，多少曾经的SOA架构拥护者也慢慢的向微服务靠拢，从概念上来讲，微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕着业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的数据存储技术、运行在不同的进程中，服务采取轻量级的通信机制和自动化的部署机制来实现通信与运维。

《凤凰架构》一书提到，微服务有九个核心的业务与技术特征，分别是：围绕业务能力构建、分散治理、通过服务来实现独立自治的组件、产品化思维、数据去中心化、强终端若管道、容错性设计、演进性设计、基础设施自动化。通俗来讲，就是要我们根据业务场景来进行颗粒度的服务拆分，每个微服务又自成一个可以独立运行的系统，可以分散不同人来管理，服务之间的通信尽可能的简单快捷，要考虑到扩容性和容错性能，由于一个系统拆分为众多的微服务所以在部署时也要完成自动化的构建，减少不必要的人为操作，以防等待时间过久或操作失误。

关于微服务系统的技术实现，我们通常使用第一代springcloud的组件或者使用第二代Springcloud alibaba的各种组件来实现，第一代springcloud组件比较盛行的是：eureka服务注册中心、ribbon负载均衡、hystrix熔断器、feign远程调用组件、zuul网关、spring cloud config分布式配置中心、spring cloud stream消息驱动组件。而第二代比较盛行的是nacos服务注册与配置中心、gateway网关组件、Sentinel流量控制熔断降级组件、seata分布式事务管理组件。当然，二者的使用大可不必将界限划分那么清楚，没必要一套系统我使用第一代的就不使用第二代了，也没必要为证明自己是搞得微服务就将所有组件堆砌而上，还是具体场景具体分析，就像我平时工作中一样，可能注册中心使用的eureka，而配置中心却用了nacos，网关则用了gateWay,远程调用则使用了feign。

微服务其实追求的是更加自由的架构风格，它抛弃了SOA中的那些条条框框的约束，用实践为标准代替了规范的约束。但这里我想讲的是，并不是所有的系统都适合微服务，也是真的没必要无脑的往微服务靠拢，一个系统能用简单的方式应对，那完全没必要耗费资金人力去拆分出各式各样的小服务来彰显自己的技术内涵，调用链路真的越短效率越高也不易出错。在这里我深有体会，前两年搞SOA时，其实公司真正经常改代码的也就业务服务和基础服务两套，所以每次出问题能很快的定位到并解决，现在整这个微服务，整个大系统的微服务就有几十个，有很多服务由其他同事管理而我自己并不熟悉，但是平时还需要调用他们提供的api,每次出现问题可能得拉会好几个同事一块讨论，问题解决难度增大了，而且上线时好多服务要理清楚上线顺序和代码，生怕哪个服务忘了上线整出问题来。之所以很多公司需要使用微服务是因为自身的业务系统愈来愈复杂、流量越来越多、数据信息变成海量才不得不去使用微服务的手段来应对，但是你的系统单一未来也很明确不会加入复杂的场景，那还是建议你保持初心吧。

5、后微服务时代

微服务时代可以说是被Spring Cloud统治的时代，分布式架构中出现的注册发现、跟踪治理、负载均衡、传输通信，我们总能在Spring cloud提供的组件中找到一个解决方案，但是这些解决方案都是软件的形式来提供的。不妨想一下，我们可不可以不局限于软件的方式，而考虑下硬件的解决方案呢？

事实上，Kubernetes提供了一套基础设施层面的解决方案，下面将展示下与传统的第一代springcloud的解决方案的对比：

Kubernetes的整套解决方案得益于这些年虚拟化技术和容器化技术的发展，当虚拟化的基础设施从单个服务的容器扩展到多个容器构成的服务集群、通信网络和存储设施时，软件与硬件的便已模糊。一旦虚拟化的硬件能够跟得上软件的灵活性，那么与业务无关的技术性问题便能从软件层面玻璃，悄无声息的在硬件基础设施之内解决，让软件只专注于业务，真正的围绕业务能力来构建团队于产品。

Kubernetes在容器生态发展中的崭露头角标志着后微服务时代的到来，但是它仍然有自己的缺点，很多场景的特殊性可能我们通过软件的手段很容易就解决了，但是在硬件层面，它针对于整个容器来管理时粒度比较粗的，很多时候难以做到有效的管控，但是我们仍然可以相信，随着Kubernetes的不断完善和进化，它会成为服务端的标准运行环境，它将会慢慢的可以取代今天Spring Cloud全家桶中大部分的组件的功能，微服务只需要考虑自身的业务本身的逻辑，这将是智能终端的最终解决方案。

6、无服务时代

谈到无服务时代我们不得不提起一个圈内耳熟能详的的词 ---- 云计算。百度百科上是这样介绍云计算的：云计算（cloud computing）是分布式计算的一种，指的是通过网络“云”将巨大的数据计算处理程序分解成无数个小程序，然后，通过多部服务器组成的系统进行处理和分析这些小程序得到结果并返回给用户。云计算早期，简单地说，就是简单的分布式计算，解决任务分发，并进行计算结果的合并。因而，云计算又称为网格计算。通过这项技术，可以在很短的时间内（几秒钟）完成对数以万计的数据的处理，从而达到强大的网络服务。现阶段所说的云服务已经不单单是一种分布式计算，而是分布式计算、效用计算、负载均衡、并行计算、网络存储、热备份冗杂和虚拟化等计算机技术混合演进并跃升的结果。云计算指通过计算机网络(多指因特网)形成的计算能力极强的系统，可存储、集合相关资源并可按需配置，向用户提供个性化服务。

有些专家预言：无服务将会成为未来云计算的主要形式。由于云计算将很多复杂的架构设计和难点处理全权托管到云端服务器来处理，因此对于开发者来讲，完全就不需要来考虑技术组件了，因为组件是现成的；不需要考虑部署了，部署托管到了云端；不需要考虑算力了，有整个数据中心支持着；不需要考虑运维了，有云计算的服务商帮你搞定。我们开发者仅仅需要纯粹的关注业务就好了。

不管是SOA架构还是微服务架构，相比起最初的单体架构来讲，架构形式好像愈来愈复杂了，对开发者的技术要求也特别高，而无服务，则是向简单发展，复杂的部分都托管向云端，未来若它成为大流行，那么所需的可能是业务极强的开发者，而不是单纯的技术牛人了，无服务它只涉及两块内容：后端设施（Backend）和函数（Function）。

后端设施是指数据库、消息队列、日志、存储，等等这一类用于支撑业务逻辑运行，但本身无业务含义的技术组件，这些后端设施都运行在云中，无服务中称其为“后端即服务”（Backend as a Service，BaaS）。

函数是指业务逻辑代码，这里函数的概念与粒度，都已经很接近于程序编码角度的函数了，其区别是无服务中的函数运行在云端，不必考虑算力问题，不必考虑容量规划（从技术角度可以不考虑，从计费的角度你的钱包够不够用还是要掂量一下的），无服务中称其为“函数即服务”（Function as a Service，FaaS）。

坦白讲，至于它今后的一个运作方式我也无法具体描述，这种模式也在积极的探索中，至今并没有一个准确的落地实现，不管如何，社会对于程序员的要求也仅仅不是技术那么简单了，做一名懂业务的程序员才是大势所趋。