关于WCF、WebAPI、WebService之间的区别总结 分布式通信技术(Distributed Communication Technologies)浅析

关于WCF、WebAPI、WebService之间的区别总结
分布式通信技术(Distributed Communication Technologies)浅析

早在1996年Gartner就前瞻性地提出了面向服务架构的思想(SOA),SOA 的走红在很大程度上归功于 Web Service 标准的成熟和应用的普及。 Service Oriented Ambiguity 中文一般理解为:面向服务架构,简称SOA,这个概念算得上微服务的鼻祖了。 SOA 的提出是在企业计算领域,就是要将紧耦合的系统,划分为面向业务的、粗粒度、松耦合、无状态的服务。服务发布出来供其他服务调用,一组互相依赖的服务就构成了SOA架构下的系统。 SOA 本质上是服务的集合。 在分布式通信技术选型中,就本人曾经使用过的基于微软平台的分布式通信进行概述,先明确一下分布式框架的三个基本需求:
  • 客户端: Web、Android、IOS、跨平台(Java 开发的系统和.NET 开发的系统可以通信)
  • 服务端:部署在Windows、Linux
  • 合约(Contract):传递的格式(REST,Json、SOAP、XML)、通信协议(HTTP、XML-RPC、TCP)、消息超时设置、消息包大小
要打造分布式平台,各家技术栈多有不错的实践,这里重点说一下微软技术栈下,丰富的技术选型:
  • .NET Remoting (15年前技术,目前已经失传)
  • Web Service (ASMX, ASP .NET Web Services,15年前技术,维护项目依然存在)
  • WCF (Windows Communication Foundation,10年前技术,维护项目中比较多)
  • Web API (5年前技术开始火起来,和跨平台需求密不可分,最近3年的新需求大部分迁移在这里了)
下面展开来说:

.NET Remoting

是2.0时代的产物, 即2004年的技术,我还没有机会实战过。在微软Roadmap中已被WCF取代(.NET Remoting做得到的事,理论上WCF都可以实现) 依据微软一份,WCF在效能上比ASP.NET Web Service快了25%-50%,比.NETRemoting快25%,弃.NET Remoting改用WCF将有性能能上的突破。 详见报告链接

Web Service

在很早前开发WebForm ASP.NET中用的比较多,因此可以将 Web Service 理解为一个基于 HTTP 协议开发的上层应用程序 Web service 是一个平台独立的,低耦合的,自包含的、基于可编程的 Web 的应用程序,可使用开放的 XML(标准通用标记语言下的一个子集)标准来描述、发布、发现、协调和配置这些应用程序,用于开发分布式的互操作的应用程序。 Simple Object Access Protocol,中文为简单对象访问协议,简称 SOAP。
1、它是基于SOAP协议的,数据格式是XML (SOAP )

2、只支持HTTP协议

3、它不是开源的,但可以被任意一个了解XML的人使用

4、它只能部署在IIS上 

SOA 不是 Web Service,Web Service 是当年最适合实现SOA的技术。

WCF

WCF是取代Web Service及.NET Remoting的接班人,我记得这个是微软2010年开始力推的技术。 我第一次是用WCF是2012年,做一个电信级项目,结合微软吹水的Silverlight技术(Silverlight技术,2013年底该技术被微软安乐死了,again!)
1、这个也是基于SOAP的,数据格式是XML

2、这个是Web Service(ASMX)的进化版,可以支持各种各样的协议,像TCP,HTTP,HTTPS,Named Pipes, MSMQ.

3、WCF的主要问题是,它配置起来特别的繁琐!!! (此处特别强调了3个感叹号 )

4、它不是开源的,但可以被任意一个了解XML的人使用

5、它可以部署应用程序中或者IIS上或者Windows服务中

WCF门槛有些太高,仅仅在Windows平台开发,而且配置文件比较复杂(WCF 客户端\WCF 服务器端,仅Binding、Behavior的复杂度就能单独写一篇文章,踩过不少坑,都是泪。) 众所周知,微软.net技术未来是.netCore,成熟的.NetCore3 2019年底就可以应用于生产系统了, 但多年来微软一直拒绝将WCF 的服务器端移植到.NET Core, 导致这个分布式技术,面临的极大的技术瓶颈,即若干年后几无可用人才来维护WCF项目,所以大约3年前开始,我知道周围朋友公司的新项目大都避而不谈WCF了。

ASP.NET Web API

随着SOAP 逐渐淡出,RESTful大行其道, Web API火了起来。 微软技术栈的工程实现是 ASP.NET Web API,而且微软建议使用 ASP.NET Core Web API 或 gRPC,它们提供基于跨平台和跨编程语言的 RPC,也能使用 gRPC 来编写代码,并替换掉一些 WCF 服务器服务。
1、一个简单的构建HTTP服务的新框架

2、在.net平台上Web API 是一个开源的、理想的、构建REST-ful 服务的技术

3、不像WCF REST Service.它可以使用HTTP的全部特点(比如URIs、request/response头,缓存,版本控制,多种内容格式)

4、它也支持MVC的特征,像路由、控制器、action、filter、模型绑定、控制反转(IOC)或依赖注入(DI),单元测试。这些可以使程序更简单、更健壮

5、它可以部署在应用程序和IIS上

6、这是一个轻量级的框架,并且对限制带宽的设备,比如智能手机等支持的很好

7、Response可以被Web API的MediaTypeFormatter转换成Json、XML 或者任何你想转换的格式。

WCF 的未来是Web API,而且微软2014年推出开源.NetCore中就有ASP.Net Core Web API,可见重视程度。

分布式技术这么多,我该选谁?

都2019年了,新项目肯定是WebAPI,原因如下:
WebAPI只要有能力发送HTTP Request跟解析JSON,比较符合微服务要求, 跨平台支持。

创建一个基于HTTP的面向资源的服务并且可以使用HTTP的全部特征时(比如URIs、request/response头,缓存,版本控制,多种内容格式),你应该选择WebAPI

让你的服务用于浏览器、手机、iPhone和平板电脑时,你应该选择Web API

双工消息模式,过SignalR和WebSockets整合(创建一个支持消息、消息队列、双工通信的服务时)

岁月在挑灯夜战中走过:亲历的软件框架

软件框架(Software framework),也称为软件架构(software architecture),是建立大型、规范软件研发的基本准则, “无规矩不成方圆”。 如,对超过10人的开发团队,超过12个月构建周期的软件产品的,是100%需要的。

在我所亲历的工作中,共有3个软件框架。 注意:软件框架和软件产品是2个概念,一个成熟的软件框架可为公司搭建好维持3年以上的基础,可在其上组合、构建不同市场的软件产品,可支撑上亿的项目簇、产品簇的。 这些框架各自实现方法不同,各有特色,但是有几个是所谓大型软件框架必备的:

  • 支持重用性
  • 支持插件组件 (依赖注入IOC)
  • 支持多人同时协同开发多个模块
  • 支持模块间通信(消息发送)
  • 可选的数据库切换
  • 可选的支持不同组件销售license控制
  • 可选的支持序列化
  • 可选的菜单配置
  • 可选的UI组件风格
  • 可选的日志记录

1. 软件架构一: 单机版、 三层架构:.net反射、观察者模式

关键词语:消息,组件,注册消息,业务视图类,数据采集、解码器、设计模式

应用周期:2005~2009年

亲历总结:至少4个版本的产品,单项目市场约50万人民币。 回头看,单机版的产品是相对较好设计的,层次也不多,方便新人较好的理解。由于未采用业内现成的框架,故有机会参与架构规则制定,故对学习的设计模式的有机会实战应用。

2. 软件架构二:RDBMS、 n层架构:Sharp Develop、IBatis、log4net 、开源框架

关键词语: Add-In插件、IOC依赖注入、OR mapping、异地团队协同开发、SQL

应用周期:2009~2012年

亲历总结:至少20个版本的产品,单项目市场约500万人民币。SD框架,是业内成熟的一个.net开源集成开发环境,其Add In尤为被人推崇,也较成熟。同时,由于多数据库的介入,如Sybase、Oracle同时要支持,故结合IBatis构建。 方便远程问题反馈,对log4net进行了移植。相对第一个土生土长的软件架构,参与构建的要少一些,更多的精力在做Add In业务模块。后来,对冗余的分层改造,如把Add in, Domain Model, DTO, Persistence, Services, Interfaces, UI这7层,在部分组件修改为: Add in, Services, Interfaces, UI4层,减少了3层。减少了系统构建的冗余度,利于新人介入,利于减少重复浪费。

3. 软件架构三: web、RIA 、SilverlightPrism框架(Unity)IBatis、末代技术

关键词语: XAP、XAML、Entity、WCF、DAO、bootstrapper、MVVM、JSON

应用周期:2012~2013年

亲历总结:至少10个版本的产品,单项目市场约500万人民币。作为微软最忠实的”信徒”,是业内极少采用SilverLight技术作大型系统案例的,更悲催的是在2012.12月,Silverlight被微软抛弃了。第一次有机会从事web的开发:通过快速学习这种末代web RIA技术和架构,搭建了目前已经商用的系统。业务方面是基于上面《软件架构二》的,换了一种新的技术而已。不过,对于习惯桌面应用系统开发者来说,还是有很大挑战的。如序列化,由于web的前端和后端两者有不同的类库,导致刚开始设计犯了不少低级错误。所幸,有链接类、条件编译,可以方便的实现前、后端源码复用,这种web的编程效率到非常高,商用的部署、升级也很方便。

 

关联文章: 职业话题杂谈