那么应用架构主要有哪些阶段呐？这里作者凭着自己的理解粗糙的讨论一下。算是对这个问题的一种探索吧！
首先我们要明确是一点是什么是应用，应用按理应该包括展示、业务逻辑呵数据存储。所以单体时代就是将上述的三层进行单体部署，也就是说前端后端都在一个进程内，就好比在一个jvm内。但是这种架构的问题就是随着业务的不断增加，项目的体积会越来越大，而且大家都知道软件工程师往往会通过跳槽来寻找与之能力相匹配的工作，因此单体的架构的维护成本很大。作者当年实习的时候就是做一个单体项目，整个war包500M，有时候看着那个war就怕出点什么问题，当然在针对这种单体项目来说只能通过反向代理的方式进行流量上的分解了，但是这种状况往往存在一种资源浪费，比较明显的就是木桶原理。
作者一直在想单体架构和mvc架构的区别，思来想去一直想不明白。我们知道mvc主要描述的是模型、视图、控制器。其中控制器就是我们的业务逻辑层的入口，视图则是展现给用户的部分，模型就是连接数据的部分。所以从这个角度来看的话，单体时代和mvc时代最大的区别就是应用封层更加清晰了。单体时代的项目可能更加类似于在servlet中write一些html脚本，而mvc时代则是将这个过程进行封装，让层次更加清晰，从而让代码的编写和理解更加容易。但是在存在的问题上并没有得到有效的解决，比如我们上边所说的木桶问题。而解决应用架构的木桶问题，就必须采用微分的思想，通过不断的合并同类项，让一些具有相同特征的代码合并然后再部署，并能够根据实际情况进行补短板。
如果项目都放到一个war包中，我们很难想象这个war包中的调用逻辑有多么复杂，真的可以用说是剪不断理还乱。估计将项目交接给谁，都是沉甸甸的压力。而且单进程的姿势往往限制了本身资源利用的能力。因为我们迫切需要将其进行多进程化拆分。而这个拆分就是我们这里所说的SOA（面向服务架构），这里的意思就是说单独的应用应该专注于其领域之内的业务，每个业务通过网络协议对外提供服务，当然这里的调用方式可以是tcp或者http。长江的SOA实现方式用web service和esb，web service通常使用soap协议，即采用http或者https来传输数据，所有的web service服务通过会注册到web service的目录中，每个服务都依赖于这个目录来发现现存的服务。esb称为企业数据总线，也是soa的一种实现，服务之间的通信和调用都是通过总线来完成，因此esb没有注册中心的一说，总线负责服务之间的解析、转化、路由，控制服务的可拆拔。esb适合不同语言开发的服务，或者不同协议开发的模块，esb可以屏蔽这些问题。web service和esb都不是一种完美的方式，web service通信协议笨重，esb的一个模块的变动可能会影响总线的变更，所以兼容性很差。近年来服务的粒度更小，进而形成微服务，一个应用被拆分成一个个独立、可部署、可运行、可维护的子服务。极大的方便了服务的复用。然后这些服务能够快速的产生新的业务逻辑。微服务和soa一脉相承，soa的思想在微服务中依然有效并得到升华。但是也有一些差异，主要如下： 目的不同，esb更加强调业务流程的编排，微服务使用一系列微小服务来实现整体流程，可以有效拆分服务，从而实现敏捷的部署和交付。
服务粒度不同，微服务拆分更加细小，从而可以方便的复用服务，从而产生新的业务。soa则通长是比较粗的粒度。协议不同，微服务通常采用统一的交互协议。兼容老系统能力较弱。说实话，云原生我也不晓得是什么，这块我们通过现有的问题来思考吧。
容量动态规划，微服务出现之后，服务容量的评估，小服务资源的浪费等问题逐渐显现。为了实现资源的动态规划，容器化逐渐成为标配，容器编排技术也逐渐走向成熟。
服务框架的臃肿，应用虽然已经微服务化，但是应用中包含大量业务无关的资源库，即使开发一个小服务也要带上臃肿的框架，为了让应用变得更加轻量，下沉更多通用能力，服务网格开始出现。
云原生技术有利于各组织在公有云私有云以及混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器，服务网格，微服务，不可变基础设施和声明式api。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统，结合可靠的自动化手段，云原生技术使工程师能够轻松对系统进行频繁和可预测的重大变更。上边对云原生说了很多，我大概的理解云原生就是类似于智能化的应用集群，在计算机中有一个思想就是如果什么问题解决不了，那就造个容器。所以说我们要让我们的应用能够智能的扩展服务来合理响应请求的流量就必须是容器化的，也就是说我们智能化以及监控的核心就是这些容器，这是云原生的关键吧。微服务它其实还是一种服务治理，但是对于服务之上的动态扩容是没有办法的，所以云原生是就更加智能，当然要想智能监控是一种基础的方式，数学上的预测也是比较重要的一部分。
