业界今天总体上，选择的主流架构都是云原生，或者是在云原生的路上。这篇文章我们谈的是架构演进，所以先罗列一下都有哪些架构
- 单体架构
- SOA架构
- 微服务架构
- 云原生架构
- 无服务架构
你看，有这么多风格的架构！对于入行不久的很多同学来说，都是从微服务架构直接开始，一上来就接触分布式系统，起点很高！但我觉得像我们这样入行久一些的老油子来说，从单体架构时代开始，一路走来，见证了各种架构的演进！也是一种幸运！
那么今天，我们一块儿来看每一种架构的演进之路，试图搞清楚在特定的时代为什么是它？或者后来为什么又不是它了？
我们从单体架构开始。单体架构是迄今为止，盛行最久最具普适性的一种架构，即便是云原生架构盛行的今天，在小规模应用场景下，单体架构任然是首选。
那么这里有一个问题，为什么单体架构可以横行这么久的时间？在软件应用领域，性能一直是一个被不断追逐且放大的话题，好比如说谈性能优化，你肯定会从关注指标开始：响应时间，吞吐量，资源使用率等。
面对性能问题，有两条探索的途径
- 分布式
- 突破单机性能瓶颈
在计算机发展的早期，遵循摩尔定律，比起分布式系统固有的复杂性，突破单机性能瓶颈成为更可行的一条途径。于是你看到了，不说可能跟普通开发同学有距离感的服务器，单说你手中的笔记本，现在是不是16G的内存，intel7代8代多核的CPU？
在这样的前提下，你说选择单体架构，是不是一个更好的选择呢？答案毫无疑问：是的。
但是，单机的性能总有一个极限，到一定的量，你就不可能要求更多了。摩尔定律在今天某种程度，已经不再那么管用。更可恶的是，软件的发展却一直向着大规模的方向在发展！
如何应对大规模软件应用需要？是的，分布式。
我们说单体架构，有它足够的简单性和高效性，这个说法是有前提的：小规模应用，隐含的意思包含：团队规模，业务规模等。但当体量上来以后，单体架构便不再简单
- 所有业务都在一个jar包，或者war包，耦合严重，想要修复一个线上问题，看半天还不敢动手
- 所有业务都在一个jar包，或者war包，问题修复了，不管改到的地方，还是没有改动的地方，全部回归测试一遍
- 所有业务都在一个jar包，或者war包，打包部署，等了半天才搞定
- 所有业务都在一个jar包，或者war包，某个模块出了问题，整个应用GG了
- 所有业务都在一个jar包，或者war包，一个数据库，有几张大表直接拖慢了整个应用
- 团队百十来号人，都在一个应用中开发，你怎么改了我的代码？你等我先改，改完后你在改！
种种以上，都在说单体架构不再简单！需要拆分。
于是业界早期探索出了几种服务拆分的架构模式
- 烟囱式架构：有些系统它们之间是没有任务信息交互的，至少在那个阶段没有这样的需求，比如说OA，财务。那么通过独立的数据库，服务器将它们直接拆分
- 微内核架构：可是在一个企业中，总有些东西是共享的，比如说人员、组织、权限。干脆把这些共享做成一个公共的服务，以插件的方式集成到其它需要的系统，进行共享
随着历史的车轮滚滚向前，企业中的烟囱式系统越来越多！有一天老总说，你们IT部能不能让我在OA系统上可以看到财务报表？或者在财务系统上看到都有谁经常请假？
我们暂且不讨论这样的需求是否合理，但终归是存在这样的需求。如何解决？
这便有了SOA（Service Oriented Architecture）架构，面向服务的架构。曾经所有研发人员看到SOA都欣喜若狂，一致以为找到了一条大规模软件发展的康庄大道！因为SOA针对分布式系统固定的一些问题：服务注册发现、治理、隔离编排，都提出了相应的解决方案。
但是SOA最终还是过时了，过时的原因不是说SOA解决不了问题。原因是
- SOA太重，不轻量级，它有严格的标准规范和协议规范，比如ESB、以及WS-* 、SOAP等各种协议
- SOA复杂性太高，导致实施成本太高，对于一线研发人员要求比较高
基于以上，注定了SOA只能是软件架构滚滚车轮前进中的一环，不具有普适性！
于是革命者总要出现，没错，微服务架构来了。
SOA架构解决了分布式系统相关的问题，通过拆分让大规模软件应用得以继续向前发展成为可能。但是SOA太重，太复杂了，在软件应用领域，任何不具有普适性的最终都会面临淘汰。比如说EJB被spring框架取代了；Weblogic、jboss被tomcat取代了。
那么既然微服务架构，要取代SOA架构，必然要有广大研发人员愿意且欣然接受它的地方，没错它带着以下特性来了
- 围绕业务能力构建：业务合理拆分，有专职的团队负责
- 分散治理：谁家的孩子谁来管，让技术异构性成为一种选择的可能
- 通过服务来实现独立自治的组件：强调隔离与自治
- 产品化思维：研发人员需要为软件产品整个生命周期负责
- 数据去中心化：独立的数据库
- 轻量级通信机制：去它的ESB，SOAP，我要Restful
- 容错性设计：可靠的系统由可容许会出错的服务来组成
- 演进式设计：系统中不容许有不可更改、不可替代的服务出现
- 基础设施自动化：CI/CD Devops
我们看到微服务架构，围绕着两个词：解耦，轻量级。等于是从SOA向前迈了一步。但是微服务架构同时提出了新的挑战
- 微服务架构对于普通研发人员是友好的，你只需要编写业务逻辑代码即可
- 微服务架构对于架构师是有挑战的，要求架构师拥有极高的专业深度和广度
不信，你看微服务提出了相关的公共关注点
- 服务发现和LB
- 配置管理
- 弹性和容错
- 自愈自动伸缩
- 发布和调度
- API管理
- 服务安全
- 服务可观测性：链路、指标、日志
以上公共关注点，普通研发人员不需要关注，架构师却是必须要要去思考的。
对于这些公共关注点，在微服务架构时代，需要在应用层去考虑解决，原因是计算机硬件难以匹配软件应用的细粒度管理和灵活性。于是你看到了spring cloud全家桶。
随着虚拟化容器化技术的发展，微服务架构不得不在应用层去解决的公共关注点，有了回归基础设施层的可能。
所以，云原生架构来了！它来了！
2017年是容器领域里程碑的一年，这一年k8s击败其它竞争对手，全面胜出。让云原生时代正式来临，那么什么是云原生呢？非官方定义有这么几个要素
- 软件应用采用微服务架构
- 配套实施CI/CD,Devops
- 软件应用发布，云平台调度
云原生架构，在基础设施层解决了微服务大部分公共关注点，比如说：服务发现LB、配置管理、弹性、自愈自动伸缩、发布和调度。因此，云原生架构时代，还被称为后微服务架构时代。
不过任然存在一些眼目前还不适合在基础设施层去解决的问题，比如偏向于业务属性安全、可观测性、流量治理、灰度等。
到此，我们还剩下最后一种架构：无服务架构（Serverless） 。
最早接触无服务架构，其实我是懵逼的！只因为它少了一个字！没错，就是这个字让我琢磨了很久。其实无服务架构，完整的是无服务器架构。
它的意思更彻底，想要让研发人员纯粹的只关注业务，至于微服务架构、云原生架构需要关注的这些关注点，统统的都不用去考虑，写好业务代码就好了。那么那些关注点都交给谁？云厂商
无服务架构，包含两个层面
- BaaS（Bankend as a Service）：后端设施即服务，比如说数据库、消息队列、日志、存储。上云就好了，花钱就好了，按需按量付费！
- FaaS（Function as a Service）：函数即服务，这里的函数代表业务逻辑，并不单指函数式编程中的函数。你只需要把业务逻辑，封装成一个可执行的jar、war包即可
无服务架构的愿景，是让研发人员只需要纯粹的关注业务，它最大的优势是简单
- 不用考虑技术组件，上云了技术组件是现成的
- 不用考虑部署过程，云端托管，自动完成部署
- 不用考虑算力和容量规划，云上算力可以认为是无限的
- 不用考虑运维，系统持续平稳运行是云厂商的事情
最后，架构探索永无止境！有未知才是乐趣！
