分层架构通过程序包或者程序的隔离构建松耦合的应用。我们以最近流行的洋葱架构模型进行分析，如图
?
包括领域实体/存储接口/服务接口，是整个程序的核心。
贫血模型
如果把大量的业务逻辑委托给服务接口实现者，领域模型显得很瘦小，就可以称之为贫血模型。这种模型下的领域对象仅仅表示“状态”。“行为”（也称为逻辑、过程）放在了N层结构的Logic/Service/Manager层中。优点是易于理解和实现，缺点是随着业务发展模型会难以表达业务领域。目前不少业内软件架构是这种模式。
贫血模型的简单图示：
充血模型
如果在领域模型中实现主要的业务逻辑，把不方便实现的业务（比如汇率结算，地理坐标解析等）委托给服务接口实现者，此时领域模型显得粗壮，就可以称之为充血模型。这种模型下的领域对象既表示“状态”又有”行为“，领域对象之间还通过聚合在一个根（聚合根），然后由根对象保证状态的一致性（类似于数据库表之间的约束一致性）。优点是模型易于跟进业务发展，容易通过重构表达最新的业务领域；缺点是不易掌握。
充血模型的简单图示：
领域模型中的对象自从被创建出来后不会一直留在内存中活动，当它不活动时会被持久化到数据库中，然后当需要的时候就会重建该对象；重建对象就是根据数据库中已存储的对象的状态重新创建对象的过程。可见持久化和重建对象是一个和数据库打交道的过程。从更广义的角度来理解，程序会像集合一样从某个类似集合的地方根据某个条件获取一个或一些对象，往集合中添加对象或移除对象。也就是说，这就需要提供一种机制，可以提供类似集合的接口来帮助程序管理对象。仓储就是基于这样的思想被设计出来的。
贫血模型下的存储仓库：实现实体对象的CRUD.
充血模型下的存储仓库：创建聚合根对象,实体对象的创建/更新/删除的行为由聚合根完成。
一般有三种服务：应用服务、领域服务、基础服务。
应用服务
调用领域服务，形成工作流程，提供事物上下文。应用服务可以直接为UI提供服务或者直接作为API暴露出去。
领域服务
在具体一个业务上下文中提供服务。比如订单生成服务提供订单的生成功能，订单的跟踪服务提供订单的执行信息。
基础服务
基础服务提供的是和业务无直接关系的工具辅助服务。比如日志，安全，通信，事件总线等等。
提供应用程序界面，支持用户输入。高效的UI开发往往会依赖UI框架，比如MVC框架。
UI框架比较多，比如MFC,WinForm,Asp.netWebForm,Asp.netMVC,Structs等等。
综上：洋葱模型的各层由外到内的单向依赖，简单直接的降低了代码之间的耦合度。
这类框架往往提供了一套操作连接/命令/结果集的接口。用户先发起连接，发生sql命令，然后得到结果集以按行（又叫记录）方式进行遍历。不同的数据库需要相应的数据库驱动和实现，但对于用户来说操作数据的方式都是一样的。
优点：
1）编写原始sql，执行效率高。
2）握有连接对象，可以自定义事物的发起，提交或者回滚。
3）可以针对不同数据存储方式定义数据访问库。
4）一般比较轻量，依赖少。
缺点：
1）编写sql容易出错，随着数据库的演变，sql的潜在错误必须依赖充分的单元测试才能消除。
2）数据库的演变，sql重构难度会逐渐增大。
ADO.Net框架的特点：接口清晰，支持离线遍历数据集，支持数据库和非数据库数据源
对象-关系映射（Object-RelationalMapping，简称ORM），以面向对象的开发方法实现数据的增删改查。
优点：
1）提高开发效率，降低开发成本
2）使开发更加对象化
3）可移植
4）可以很方便地引入数据缓存之类的附加功能
缺点：
1）自动化进行关系数据库的映射需要消耗系统性能。其实这里的性能消耗还不大，一般来说都可以忽略之（除非在性能特别关键应用）。
2）在处理多表联查、where条件复杂之类的查询时，ORM的语法会变得复杂。
典型框架：
框架
特点
开发语言
Dapper
半自动；轻量级；自己写sql语句,可操作性强,小巧
C#
Entity?Framework
全自动；较重量级；支持写linq和原生sql，功能强大
C#
Model
???负责提供界面绑定的数据，以及业务逻辑处理。
View
???负责提供用户和应用之间的交互界面。不同类型的应用交互界面不同，可以是桌面程序窗口和web页面。
Controller
???负责收集用户输入事件，并分配事件给对该事件感兴趣的模型处理。对MVC的理解难点在于控制器的解读，在下面我们会用经典MVC模式和后端MVC模式分析。
这种模式大量用在复杂交互界面的桌面应用程序，比如MFC框架；以及web富应用框架中，比如AngularJS1（尽管有人称之为为MVVM框架）。
图示：
控制器把输入事件通知给对该事件感兴趣的模型，模型更新自己的状态并引起视图更新，然后将更新事件通知控制器，此时如果有对该更新事件感兴趣的模型会进一步进行处理。事实上控制器和模型之间构成了订阅/发布关系。
MVVM框架：把Controller变成了ViewModel，它与View进行双向绑定：View的变动，自动反映在ViewModel，反之亦然。
MVVM框架图示：
自web应用普及开来，涌现了不少后端MVC模式，比如JAVA的Structs,.NET的Asp.netMVC等。由于页面在浏览器中显示，用户输入通过http到达后端。
与经典MVC模式不同，控制器直接获得输入事件（http请求），调用对应的模型，模型处理完后传递视图对象（VO）给控制器，控制器找到合适的视图并传递VO给视图，视图产生html/json/文件流等资源，应用程序根据资源类型Response结果。通常后端MVC的控制负责的处理比较简单；而复杂的用户输入可以用前端MVC框架实现（类似经典MVC模式）。
框架
特点
开发语言
前后(端)
Asp.netMVC
支持WebForm和Razor
C#
后
Nancy
轻量，支持WebForm和Razor，路由更灵活
C#
后
AngularJS
功能完整，支持双向绑定，开发效率高，运行效率一般，v2版本推翻v1,性能上提高，开发更组件化
js
前
React
思路新颖，运用VirtualDom技术，性能高；但目标是UI组件，需配合其他库搭建完整MVC框架
js
前
Vue
非常小巧，核心库专注视图层。需要搭建其他组件实现完整MVC框架
js
前
模型负责提供视图数据和业务逻辑处理，视图负责提供用户交互界面，控制器将输入事件分配到对该事件感兴趣的模型。控制器居于中心位置，类似于功能胶水，但功能仅限于胶水是它不错的定位；避免写入过多业务逻辑代码使控制器变得复杂，难以维护。
用现实生活中例子引入：由于汽车依赖轮胎，如果按照正向依赖，则汽车厂商需要根据轮胎供应商能提供的轮胎来定义自己的接口（螺丝，大小等）。但如果依赖倒置一下（让轮胎厂商依赖汽车厂商），则汽车厂商只需要定义自己的接口（螺丝，大小等）由轮胎厂商去按照这个规格规范生产，就成为现在汽车行业的例子。这种依赖倒置是一个思想概念，需要一个容器来实现，这就是IOC框架。
图示：
依赖倒置(DependencyInversionPrinciple,英文缩写为DIP)
????从依赖具体类变换为依赖抽象就叫依赖倒置，这是一种设计原则。
控制反转（InversionofControl，英文缩写为IoC）
?????依赖倒置的一种实现方式，通常用于构建框架，比如WinForm，WebForm程序中你可以自定义具体的窗口类，然后在窗口初始化和虚函数里面写代码，框架会按照自己的一套流程运行：启动具体窗口，调用初始化方法，在不同的运行节点调用对应的虚函数。运行控制权始终在框架手中而不是我们写的代码。
依赖注入(DependencyInjection，英文缩写为DI)
????依赖注入也是依赖倒置的一种具体实现，是类库设计的一种常用模式。类库基于依赖模式设计：调用者依赖于接口，而不是具体的实现，调用者在运行时被注入所依赖接口的具体实现。注入方法不在此处赘述。
IOC框架
???IOC框架包括了控制反转和依赖注入功能。以下通过QA的方式来读懂IOC框架：
??Q:IOC的控制是对什么的控制？
??A:?是对应用程序中对象的创建和生命周期的控制。
??Q:正向控制是什么样子？
??A:?由应用程序new对象，并在合适的时候释放对象。
??Q:反转控制是什么样子？
??A:?对象的创建和生命周期管理由IOC框架控制，而不是应用程序控制，这种情形与正向控制相反就叫做反转控制。
?Q:控制反转带来了什么好处？
?A:?控制反转不仅减轻了应用程序的代码复杂性，更给IOC框架的扩展性带来好处，比如IOC框架可以实现对象单例模式，多例模式，引入事物管理，日志管理，安全管理等等功能，比如Spring产品家族。
?Q:依赖是什么？
A:?依赖包括：临时使用，关联，聚合，组合，依赖关系从左到右增强。可以参考UML相关概念描述。
Q:注入的目的是什么？
A:?使得对象可以依赖抽象，而不是具体实现类。主要好处是让应用程对象之间松耦合。
MVC模式的价值在于更好的处理洋葱架构的UI层。
框架
特点
开发语言
Unity
包含于微软企业库中，性能稳定
C#
Autofac
轻量，性能很高
C#
?
多层架构适合整体式程序，即一个程序实现了系统全部功能。随着企业规模越来越大，会面对不断的新需求和需求改动，在一个程序中进行扩展变得越来越难以进行。同时面对大并发的业务请求，程序在一个进程或者多个进程中运行都难以克服一个低效运行的功能代码造成的性能瓶颈。
人们找到了解决办法：将程序功能分割成服务程序，各服务程序在水平方向上并行开发和部署，由API连接各服务，这种方式使降低服务之间的耦合，部署更加灵活，性能调优可以针对独立的服务。
面向服务的体系结构（英语：service-orientedarchitecture）是构造分布式计算的应用程序的一种方法。它将应用程序功能作为服务提供给最终用户或者其他服务使用。
它采用开放标准、与软件资源进行交互并采用表示的标准方式。
图示：
Policy(策略)
???服务提供者有时候会要求服务消费者与某种策略通信。比如要求消费者提供安全标识，才能获取某项服务。
Endpoint(终结点)
???终结点是一个描述提供或者接受服务的方式，包括网络协议，域名或者IP,端口信息。
Contracts(合约)
???服务合约是服务提供者（通常是远程的）和使用者（客户）之间使用合约语言（XML、JSON、JavaObject等）约定数据输入和数据输出的一份协议。
Messages(消息)
???服务提供的消息，应满足服务的合约。
服务治理SOA最大的话题，涵盖了以下内容：
服务定义（服务的范围、接口和边界）
服务部署生命周期（各个生命周期阶段）
服务版本治理（包括兼容性）
服务迁移（启用和退役）
服务注册中心（依赖关系）
服务消息模型（规范数据模型）
服务监视（进行问题确定）
服务所有权（企业组织）
服务测试（重复测试）
服务安全（包括可接受的保护范围）
为了解决以上问题，最为流行的做法在SOA架构中增加ESB（EnterpriseServiceBus，即企业服务总线）集成。
微服务是SOA的进化版本，把服务做到微型化。
微服务架构下通过RESTAPI提供提服务，所以不强调策略和合约，只要服务提供方暴露终结点和提供消息就足够了。
SOA会遇到的治理问题，在微服务中一样会暴露出来。由于微服务系统中服务数量更多，生产环境中出现的各种问题更加突出。一部分人觉得微服务架构应该是去中心化，不需要ESB的中介作用，事实上为微服务的网关可以具备ESB的一些功能，比如安全检查/事物管理/复杂的工作流程等功能。
六种常见的微服务设计架构模式
1、聚合器微服务设计模式
这是一种最常见也最简单的设计模式
聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。
2、代理微服务设计模式
这是聚合模式的一个变种，如下图所示：
在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。
3、链式微服务设计模式
这种模式在接收到请求后会产生一个经过合并的响应，如下图所示：
在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。
4、分支微服务设计模式
这种模式是聚合器模式的扩展，允许同时调用两个微服务链，如下图所示：
?
5、数据共享微服务设计模式
自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的“单体应用（monolithicapplication）”时，SQL数据库反规范化可能会导致数据重复和不一致。
因此，在单体应用到微服务架构的过渡阶段，可以使用这种设计模式，如下图所示：
在这种情况下，部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言，这是一种反模式。
6、异步消息传递微服务设计模式
虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应，如下图所示：
优点
关键点：复杂度可控，独立按需扩展，技术选型灵活，容错，可用性高
1）它解决了复杂性的问题。它会将一种怪异的整体应用程序分解成一组服务。虽然功能总量不变，但应用程序已分解为可管理的块或服务。每个服务都以RPC或消息驱动的API的形式定义了一个明确的边界；Microservice架构模式实现了一个模块化水平。
2）这种架构使每个服务都能够由专注于该服务的团队独立开发。开发人员可以自由选择任何有用的技术，只要该服务符合API合同。
3）Microservice架构模式使每个微服务都能独立部署。开发人员不需要协调部署本地服务的变更。这些变化可以在测试后尽快部署。例如，UI团队可以执行A|B测试，并快速迭代UI更改。Microservice架构模式使连续部署成为可能。
4）Microservice架构模式使每个服务都可以独立调整。您可以仅部署满足其容量和可用性限制的每个服务的实例数。此外，您可以使用最符合服务资源要求的硬件。
缺点
关键点（挑战）：多服务运维难度，系统部署依赖，服务间通信成本，数据一致性，系统集成测试，重复工作，性能监控等
1）一个缺点是名称本身。术语microservice过度强调服务规模。但重要的是要记住，这是一种手段，而不是主要目标。微服务的目标是充分分解应用程序，以便于敏捷应用程序开发和部署。
2）微服务器的另一个主要缺点是分布式系统而产生的复杂性。开发人员需要选择和实现基于消息传递或RPC的进程间通信机制。此外，他们还必须编写代码来处理部分故障，因为请求的目的地可能很慢或不可用。
3）微服务器的另一个挑战是分区数据库架构。更新多个业务实体的业务交易是相当普遍的。但是，在基于微服务器的应用程序中，您需要更新不同服务所拥有的多个数据库。使用分布式事务通常不是一个选择，而不仅仅是因为CAP定理。许多今天高度可扩展的NoSQL数据库都不支持它们。你最终不得不使用最终的一致性方法，这对开发人员来说更具挑战性。
4）测试微服务应用程序也更复杂。服务类似的测试类将需要启动该服务及其所依赖的任何服务（或至少为这些服务配置存根）。再次，重要的是不要低估这样做的复杂性。
5）Microservice架构模式的另一个主要挑战是实现跨越多个服务的更改。例如，我们假设您正在实施一个需要更改服务A，B和C的故事，其中A取决于B和B取决于C.在单片应用程序中，您可以简单地更改相应的模块，整合更改，并一次性部署。相比之下，在Microservice架构模式中，您需要仔细规划和协调对每个服务的更改。例如，您需要更新服务C，然后更新服务B，然后再维修A.幸运的是，大多数更改通常仅影响一个服务，而需要协调的多服务变更相对较少。
6）部署基于微服务的应用程序也更复杂。单一应用程序简单地部署在传统负载平衡器后面的一组相同的服务器上。每个应用程序实例都配置有基础架构服务（如数据库和消息代理）的位置（主机和端口）。相比之下，微服务应用通常由大量服务组成。例如，每个服务将有多个运行时实例。更多的移动部件需要进行配置，部署，扩展和监控。此外，您还需要实现服务发现机制，使服务能够发现需要与之通信的任何其他服务的位置（主机和端口）。传统的基于故障单和手动操作的方法无法扩展到这种复杂程度。因此，成功部署微服务应用程序需要开发人员更好地控制部署方法，并实现高水平的自动化。
?
框架
前期开发效率
迭代开发效率
扩展能力
维护性
整体式
高
中，通常越来越低
低
高
SOA架构
中
中，趋势比较平稳
中
中
微服务架构
低
高，趋势比较平稳
高
低
如果是小团队，中小项目用整体式开发更好；如果有大量或者难以重构的遗留代码建议采用SOA架构；比如是全新的项目且预计将来会快速迭代成大项目则建议用微服务架构。
框架
特点
是否开源
WCF
微软出品，目前仅在windows下运行。它支持HTTP、TCP、命名管道之间的单向和双向消息通信，此外，在第三方扩展的帮助下，还支持任何基于消息的传输格式。
客户端开源
?
Surging
开发语言
C#
开发方
个人
维护状态
一般
互联网应用案例
暂无
基于协议
IPC
可用的语言
C#
分布式事物
否
无状态部署
是
服务器治理
提供高性能RPC远程服务调用，采用Zookeeper、Consul作为surging服务的注册中心，集成了哈希，随机，轮询作为负载均衡的算法，RPC集成采用的是netty框架，采用异步传输
分布式配置
有
单元测试
未知
?
文章参考：
https://www.cnblogs.com/gxwang/p/10075049.html
https://www.jianshu.com/p/3323754ae3e7