系统应用架构演变（转载）
0. ORM应用
就是所有的都写在一起 ，这里就不做解释了吧，
1. 传统的垂直应用的架构：
就是我们现在企业中最常用的MVC架构，它有一个主要的特点就是技术单一，开发上手快，测试，部署都是比较简单的
MVC的三层结构：
a． 最前端的是V(view),主要是用于前端页面展示，使用jsp,js,html+css等
b． 中间为调度控制层（Control）,主要是用于前端web请求的分发，然后调度后台的逻辑执行，可以通过struts2或者spring mvc来实现
c． 第三层为应用模型层（Model），模型是应用程序上的字体部分，模型代表了业务逻辑和业务数据
标准的MVC模式并不包含数据访问层，在开发中我们有一些架构可以解决这个问题，比如使用了我们的ORM(对象关系映射框架)来实现与数据库的访问，可以使用mybatis和hebernate,这俩个框架都不同程度的封装了JDBC
这种垂直架构面临的挑战：
1. 复杂应用开发的维护成本很高，部署效率低
2. 团队合作弱，多个项目的或者同一个项目的公共模块重复开发，增加了代码量的冗余
3. 系统可靠性降低，随业务的不断增加，访问量增大，网络流量增大，数据库连接增多，这都是将要面临的问题
4. 维护困难：业务代码不断加大，功能不断加多，在这种垂直的架构中无法对已有的服务拆分，改一个地方，其它地方会有影响
2. RPC架构
RPC架构可以让远程过程（服务）调用更加简单、透明，RPC框架负责屏蔽底层的传输方式（TCP或者是UDP）、序列化方式（XML、JSON、二进制）和一些通信的细节，开发者不需要关心具体的通信细节和调用过程
RPC架构的核心技术：
1. 远程服务提供者需要以某种形式提供服务调用相关的信息，包括但不局限于服务接口定义、数据结构，或者中间态的服务定义文件，服务调用者需要通过一定的途径获取远程服务调用相关信息。
2. 远程代理对象：服务调用者调用的服务实际是远程服务的本地代理，对于我们的java来说其实就是jdk的动态代理，通过动态代理的拦截机制，将本地调用封装成远程服务调用
3. 通信：RPC框架与具体的协议无关
4. 序列化
RPC架构面临的挑战：
随着服务越来越多的时候，服务间依赖关系变得错综复杂，服务的调用量越来越大，服务的容量问题就会暴露出来了，某个服务在那个机器上，什么时候该增加节点，这都是问题
将业务服务化后，随之而来的就是服务治理的问题，目前业界开源的RPC框架的服务治理能力都不是很健全，当应用大规模服务化后会面临许多服务治理方面的挑战，需要解决这些问题，必须通过服务框架+服务治理来完成，但凭RPC框架就比较吃力了
3. SOA服务化架构
SOA是一种粗粒度，松耦合的以服务为中心的架构，接口间通过定义明确的协议和接口进行通信。它可以更加从容地应对复杂企业系统集成和需求的快速变化
SOA面向服务的一般原则总结如下
1. 服务和复用
2. 服务共享一个标准的契约：比如说一个接口
3. 服务间是松耦合的
4. 服务是底层逻辑的抽象：只有经服务契约所暴露的服务对外部可见，契约外的底层逻辑实现是不可见的
5. 服务是可以组合的：多个服务可以被编排组合成一个新的服务
6. 服务是自治的不依赖其它服务
7. 服务是可以被自动发现的:服务发布上线后，允许被其它消费者自动发现
SOA架构面临的挑战：
SOA架构解决了应用服务化的问题，随着服务化实践的不断深入，服务规模越来越大，服务治理面临的挑战也是越来越多
4. 微服务架构例如dubbo/springcloud
微服务架构是一种服务化架构风格，通过将功能分散到各个离散的服务中以实现对解决方案的解耦
微服务的主要特征如下：
1. 原子服务，专注于做一件事情，与面向对象中的“单一职责原则”类似，实现高内聚，低耦合
2. 高密度部署：重要的服务可以独立进程部署，非核心服务可以独立打包，合设到统一进程中去，服务被高密度部署
3. 敏捷交付：服务由小研发团队负责设计、开发、测试、部署、线上治理运维整个服务的生命周期
4. 微治理：服务足够小，功能单一，可以独立打包、部署、升级。不依赖其它的服务，实现了局部自治
这就是我们应用架构的演进，从耦合到微服务，便于管理和服务的治理
