框架Framework

框架Framework

设计模式（Design pattern：是一套被反复使用、多数人知道的、经过分类编目的、代码设计经验的总结。从定义上看，它涉及到了代码级别，侧重于解决实际的现实的问题。比如我们应该如何为不同的商品设计折扣的方式，采用策略模式呗。

框架（Framework）：是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法;另一种定义认为，框架是可被应用开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。从定义看，它涉及到了一堆构件，以及这些构件之间的依赖关系、责任分配和流程控制等，说白了就是一堆类而已。这些类以及之间的关系构成了框架。比如想要让用户通过Servlet来访问页面，怎么办？用Struts呗。

架构模式（架构风格）：一个架构模式描述软件系统里的基本的结构组织或纲要。架构模式提供一些呈先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。从定义上来看，它是在指导我们如何组织代码，是一种具有指导意义的思想，比如要解决系统的数据与显示分离的问题，那就使用MVC模式呗。

软件架构（software architecture）：是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。比如，我们要开发一个在线测评系统，使用什么架构呢？轻量级的SSH还是重量级的EJB？自己决定吧。

关注点分离所对应的英文是Separation of Concerns,简称SOC。它是最经典的架构设计原 则之一，在许多架构设计中被广泛使用。关注点分离原则为我们的架构设计提出了三点要求。

架构中需要变化的部分，一定要能够非常清晰地被识别出来。

若架构中某部分发生变化，则该变化不会影响到其他部分。

若架构中某部分需要扩展，则该扩展也不会影响到其他部分。

架构能做到关注点分离，才能做到真正意义上的解耦，这是架构师们需要努力实现的目 标。如果大家要问，关注点分离做得最有效的落地实践是什么？我们首先能想到的就是“前后端分离”。

前端需要考虑界面展现与数据展现问题，后端需要考虑业务逻辑与数据逻辑问题。

针对前端工程师而言，需要将界面展现与数据展现相分离；针对后端工程师而言，不仅要清晰地理解业务逻辑，善于将数据进行合理的建模，最终还要做到将业务逻辑与数据逻辑相分离。

业务逻辑对于我们而言已经很清楚了，但数据逻辑包括哪些呢？最直接的就是一个个对应于数据库中每张数据表的实体对象，它有一个很好听的名字：数据访问对象，即Data Access Object,简称DAO。很明显，这一层数据直接和底层数据库打交道，我们将它们从业务逻辑中分离出来，并加以封装。也就是说，没必要为每一个DAO对象初始化的过程去编写大量的代码，这些代码应该封装到一个框架中。我们只需要编写相应的SQL语句，并将这些SQL语句从业务代码中分离出来，最终将执行SQL语句所得到的结果集映射到DAO对象中即可。

架构设计

单一应用架构ORM

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。

垂直应用架构MVC

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。

分布式服务架构RPC

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

流动计算架构SOA

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。

MVC

Model模型-View视图-Controller控制器

View视图

视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。

Model模型

模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。

业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据 保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。

Controller控制器

可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。

模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。这实际上是一种模型的变化-传播机制。模型、视图、控制器三者之间的关系和各自的主要功能

1）最上面的一层，是直接面向最终用户的"视图层"（View）。它是提供给用户的操作界面，是程序的外壳。
2）最底下的一层，是核心的"数据层"（Model），也就是程序需要操作的数据或信息。
3）中间的一层，就是"控制层"（Controller），它负责根据用户从"视图层"输入的指令，选取"数据层"中的数据，然后对其进行相应的操作，产生最终结果。

这三层是紧密联系在一起的，但又是互相独立的，每一层内部的变化不影响其他层。每一层都对外提供接口（Interface），供上面一层调用。这样一来，软件就可以实现模块化，修改外观或者变更数据都不用修改其他层，大大方便了维护和升级。

MVC优点与不足

MVC的优点:
大部分用过程语言比如ASP、PHP开发出来的Web应用，初始的开发模板就是混合层的数据编程。例如，直接向数据库发送请求并用HTML显示,开发速度往往比较快,但由于数据页面的分离不是很直接,因而很难体现出业务模型的样子或者模型的重用性。产品设计弹性力度很小，很难满足用户的变化性需求。MVC要求对应用分层，虽然要花费额外的工作，但产品的结构清晰，产品的应用通过模型可以得到更好地体现。

首先，最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快速变化下，可能有多种方式访问应用的要求。例如，订单模型可能有本系统的订单，也有网上订单，或者其他系统的订单，但对于订单的处理都是一样，也就是说订单的处理是一致的。按MVC设计模式，一个订单模型以及多个视图即可解决问题。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变，也易于维护。 其次，由于模型返回的数据不带任何显示格式，因而这些模型也可直接应用于接口的使用。

再次，由于一个应用被分离为三层，因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动MVC的模型层。

控制层的概念也很有效，由于它把不同的模型和不同的视图组合在一起完成不同的请求，因此，控制层可以说是包含了用户请求权限的概念。

最后，它还有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。

MVC的不足

MVC的不足体现在以下几个方面：

（1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。

（2）视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。

（3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

（4） 目前，一般高级的界面工具或构造器不支持MVC架构。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。

RPC远程调用

分布式基石

Dubbo

远程服务调用的分布式微服务框架，RPC 远程服务调用方案，以及 SOA 服务治理方案

Dubbo 未来的定位并不是要成为一个微服务的全面解决方案，而是专注在 RPC 领域，成为微服务生态体系中的一个重要组件。

RPC、RMI、SOAP、REST的区别

RMI(remote method invocation，面向对象的远程方法调用)
RPC（remote procedure call，远程过程调用）
SOAP(simple object access protoal，简单对象访问协议)
REST(representational state transfer，表达性状态转移)

可以都理解为调用远程方法的一些通信技术“风格”：

· RMI就好比它是本地工作，采用tcp/ip协议，客户端直接调用服务端上的一些方法。优点是强类型，编译期可检查错误，缺点是只能基于JAVA语言，客户机与服务器紧耦合。

· RPC是一个泛化的概念，严格来说一切远程过程调用手段都属于rpc范畴，包括rmi、hessian、soap、thrift、protobuf等等。

· SOAP是在XML-RPC基础上，使用标准的XML描述了RPC的请求信息（URI/类/方法/参数/返回值）。因为XML-RPC只能使用有限的数据类型种类和一些简单的数据结构，SOAP能支持更多的类型和数据结构。优点是跨语言，非常适合异步通信和针对松耦合的C/S，缺点是必须做很多运行时检查。

· REST一般用来和SOAP做比较，它采用简单的URL方式来代替一个对象，优点是轻量，可读性较好，不需要其他类库支持，缺点是URL可能会很长，不容易解析。

目前三种主流的web服务实现方法：

REST（新型）：表象化状态转变 (软件架构风格）RESTEasy、Wink、CXF、Axis2…….

SOAP（比较成熟）：简单对象访问协议 Xfire、Axis2、CXF、Axis1

XML-RPC（淘汰）：远程过程调用协议（慢慢被soap 所取代）

SOA