负责按顺序处理 Channel 中的事件,摘要即时通讯云网易云信于2018年01月04日发布4.6版

摘要近日,苹果开源了一款基于事件驱动的高性能跨平台网络应用程序开发框架
SwfitNIO,它有点类似 Netty,但开发语言使用的是
Swift。1、SwiftNIO是什么SwfitNIO
实际上是一个底层工具,用于开发高性能的网络应用程序,作为“每连接一个线程”的替代方案。为了提升性能,SwfitNIO
使用了非阻塞 IO,这从它的名字就可以看出来。非阻塞 IO 与阻塞式 IO
非常不一样,因为不管是往网络上发送数据还是从网络上接收数据,应用程序都无需等待,系统内核会在有可操作的
IO 时通知 SwfitNIO。SwfitNIO 并不会提供类似 Web
框架那样的解决方案,而是致力于为上层框架提供底层的构建块。在开发 Web
应用程序时,大部分开发者不会直接使用 SwfitNIO,他们会从 Swift
生态系统众多的 Web 框架中选择一个。不过,这些框架中的大部分都使用了
SwfitNIO。2、受支持的平台SwfitNIO 的目标是支持所有可以运行 Swift
的平台。目前,SwfitNIO 可以在 macOS 和 Linux 上运行,包括:Ubuntu
14.04+macOS 10.12+3、基本架构SwfitNIO 包含了几种基本构建块,所有的
SwfitNIO
应用程序都是由这几种组件组成的。EventLoopGroupEventLoopChannelChannelHandlerBootstrapByteBuffer▶
EventLoopPromise 和 EventLoopFutureEventLoop 是 SwfitNIO 最基本的 IO
原语,它等待事件的发生,在发生事件时触发某种回调操作。在大部分 SwfitNIO
应用程序中,EventLoop 对象的数量并不多,通常每个 CPU 核数对应一到两个
EventLoop 对象。一般来说,EventLoop
会在应用程序的整个生命周期中存在,进行无限的事件分发。EventLoop
可以组合成 EventLoopGroup,EventLoopGroup 提供了一种机制用于在各个
EventLoop 间分发工作负载。例如,服务器在监听外部连接时,用于监听连接的
socket 会被注册到一个 EventLoop 上。但我们不希望这个 EventLoop
承担所有的连接负载,那么就可以通过 EventLoopGroup 在多个 EventLoop
间分摊连接负载。目前,SwiftNIO 提供了一个 EventLoopGroup
实现(MultiThreadedEventLoopGroup)和两个 EventLoop
实现(SelectableEventLoop 和
EmbeddedEventLoop)。MultiThreadedEventLoopGroup 会创建多个线程(使用
POSIX 的 pthreads 库),并为每个线程分配一个 SelectableEventLoop
对象。SelectableEventLoop 使用选择器(基于 kqueue 或
epoll)来管理来自文件和网络 IO 事件。EmbeddedEventLoop 是一个空的
EventLoop,什么事也不做,主要用于测试。▶
Channels、ChannelHandler、ChannelPipeline 和 ChannelHandlerContext尽管
EventLoop
非常重要,但大部分开发者并不会与它有太多的交互,最多就是用它创建
EventLoopPromise 和调度作业。开发者经常用到的是 Channel 和
ChannelHandler。每个文件描述符对应一个 Channel,Channel
负责管理文件描述符的生命周期,并处理发生在文件描述符上的事件:每当
EventLoop 检测到一个与相应的文件描述符相关的事件,就会通知
Channel。ChannelPipeline 由一系列 ChannelHandler 组成,ChannelHandler
负责按顺序处理 Channel 中的事件。ChannelPipeline
就像数据处理管道一样,所以才有了这个名字。ChannelHandler 要么是
Inbound,要么是 Outbound,要么两者兼有。Inbound 的 ChannelHandler
负责处理“inbound”事件,例如从 socket 读取数据、关闭 socket
或者其他由远程发起的事件。Outbound 的 ChannelHandler
负责处理“outbound”事件,例如写数据、发起连接以及关闭本地
socket。ChannelHandler
按照一定顺序处理事件,例如,读取事件从管道的前面传到后面,而写入事件则从管道的后面传到前面。每个
ChannelHandler 都会在处理完一个事件后生成一个新的事件给下一个
ChannelHandler。ChannelHandler
是高度可重用的组件,所以尽可能设计得轻量级,每个 ChannelHandler
只处理一种数据转换,这样就可以灵活组合各种
ChannelHandler,提升代码的可重用性和封装性。我们可以通过
ChannelHandlerContext 来跟踪 ChannelHandler 在 ChannelPipeline
中的位置。ChannelHandlerContext 包含了当前 ChannelHandler
到上一个和下一个 ChannelHandler 的引用,因此,在任何时候,只要
ChannelHandler 还在管道当中,就能触发新事件。SwiftNIO 内置了多种
ChannelHandler,包括 HTTP 解析器。另外,SwiftNIO 还提供了一些 Channel
实现,比如 ServerSocketChannel(用于接收连接)、SocketChannel(用于 TCP
连接)、DatagramChannel(用于 UDP socket)和
EmbeddedChannel(用于测试)。▶ BootstrapSwiftNIO 提供了一些 Bootstrap
对象,用于简化 Channel 的创建。有些 Bootstrap
对象还提供了其他的一些功能,比如支持 Happy Eyeballs。目前 SwiftNIO
提供了三种 Bootstrap:ServerBootstrap(用于监听
Channel),ClientBootstrap(用于 TCP Channel)和 DatagramBootstrap(用于
UDP Channel)。▶ ByteBufferSwiftNIO 提供了 ByteBuffer,一种快速的
Copy-On-Write 字节缓冲器,是大部分 SwiftNIO
应用程序的关键构建块。ByteBuffer
提供了很多有用的特性以及一些“钩子”,通过这些钩子,我们可以在“unsafe”的模式下使用
ByteBuffer。这种方式可以获得更好的性能,代价是应用程序有可能出现内存问题。在一般情况下,还是建议在安全模式下使用
ByteBuffer。▶ EventLoopPromise 和
EventLoopFuture并发代码和同步代码之间最主要的区别在于并非所有的动作都能够立即完成。例如,在向一个
Channel 写入数据时,EventLoop
有可能不会立即将数据冲刷到网络上。为此,SwiftNIO 提供了
EventLoopPromise和
EventLoopFuture,用于管理异步操作。EventLoopFuture实际上是一个容器,用于存放函数在未来某个时刻的返回值。每个
EventLoopFuture对象都有一个对应的
EventLoopPromise,用于存放实际的结果。只要 EventLoopPromise
执行成功,EventLoopFuture 也就完成了。通过轮询的方式检查 EventLoopFuture
是否完成是一种非常低效的方式,所以 EventLoopFuture
被设计成可以接收回调函数。也就是说,在有结果的时候回调函数会被执行。EventLoopFuture负责处理调度工作,确保回调函数是在最初创建
EventLoopPromise 的那个 EventLoop
上执行,所以就没有必要再针对回调函数做任何同步操作。4、SwiftNIO
的设计哲学SwiftNIO
的目标是要成为强大的网络应用程序开发框架,但并不想为所有的层次抽象提供完美的解决方案。SwiftNIO
主要专注在基本的 IO
原语和底层的协议实现上,将其他层次的抽象留给广大的社区去构建。SwiftNIO
将成为服务器端应用程序的构建块,但不一定就是应用程序直接拿来使用的框架。对性能有很高要求的应用程序可能会直接使用
SwiftNIO,减少上层抽象所带来的开销。SwiftNIO
可以帮助这些应用程序在提升性能的同时降低维护成本。SwiftNIO
还为某些场景提供了有用的抽象,高性能的网络服务器可以直接使用这些抽象。SwiftNIO
的核心仓库提供了一些非常重要的协议实现,比如
HTTP。不过,我们认为,大部分协议的实现应该要与底层的网络栈分开,因为它们的发布节奏是很不一样的。为此,我们鼓励社区自己去实现和维护他们的协议实现。实际上,SwiftNIO
提供的一些协议实现最初就是由社区开发的,比如 TLS 和
HTTP/2。5、相关资源源码托管:
文档:
SwiftNIO:聊天客户端:
客户端:
服务器端:
服务器:

摘要即时通讯云网易云信于2018年01月04日发布4.6版,本次更新为主要版本更新,详情见文章内容。发布的版本本次发布的版本号为
4.6版,更新时间为:2018年01月04日。iOS
更新内容新增新增在后台自动执行重连开关@interface NIMSDKConfig :
NSObject/** * 是否禁止后台重连 * @discusssion 默认为
NO。即默认情况下,当程序退到后台断开连接后,如果 App 仍能运行,SDK
将继续执行自动重连机制。设置为 YES
后在后台将不自动重连,重连将被推迟到前台进行。 *
只有特殊用户场景才需要此设置,无明确原因请勿设置。 */@property
(nonatomic,assign) BOOL
reconnectInBackgroundStateDisabled;@end新增聊天室历史记录拉取可以按类型筛选字段/**
* 检索服务器历史消息选项 (服务器) */@interface
NIMHistoryMessageSearchOption : NSObject/** * 查询的消息类型 *
@discusssion 消息类型组合,默认为 nil ,搜索全类型。
此参数只对聊天室会话有效 */@property (nonatomic,copy)
NSArray<NSNumber *>
*messageTypes;@end易盾反垃圾,支持对单条消息配置对应的反垃圾业务规则,NIMAntiSpamOption新增字段
businessId。/** * 反垃圾选项 * @discussion
这个选项用于配置易盾反垃圾,设置 enabled 为 YES (默认为 NO)
后该消息进投递到易盾系统进行反垃圾检测 (需要开启易盾服务)
*/@interface NIMAntiSpamOption : NSObject/** *
用户在易盾配置的额外反垃圾的业务ID */@property
(nullable,nonatomic,copy) NSString
*businessId;@end新增聊天室队列权限修改,NIMChatroomUpdateTag中新增字段
NIMChatroomUpdateTagQueueModificationLevel修正聊天室缓存用户扩展信息,保证掉线重连后不清除Android
更新内容新增1. 易盾反垃圾支持对单条消息配置对应的反垃圾业务规则。2.
新增支持海外推送 FCM 以及魅族推送。3. 支持配置聊天室队列管理权限。4.
支持群管理员撤销其他人消息。5. 支持视频消息获取远程缩略图 url。6.
聊天室历史记录拉取可按类型筛选。变更1. 修复酷派偶现崩溃问题。2.
接口变更:List<NimRobotInfo> getRobotInfo(List<String>
accounts);改为List<NimRobotInfo>
getRobotInfoList(List<String>
accounts);3.MessageNotifierCustomization新增消息撤回通知文案自定义接口:/**
* 定制消息撤回提醒文案 * @param revokeAccount 撤回操作者账号 * @param
item 被撤回的消息 * @return */String makeRevokeMsgTip(String
revokeAccount, IMMessage
item);4.ChatRoomPartClearAttachment附件内容变更getContentMap()返回由Map<String,Object>变为Map<String,
String>getChatRoomQueueChangeType()返回ChatRoomQueueChangeType.PARTCLEARWindows(PC)
SDK
更新内容新增群主或群管理员可以撤回其他群成员发送的消息的功能用户配置的对某单条消息另外的反垃圾的业务ID的功能视频消息主动获取封面功能NOS域名迁移NOS加速地址,上传、下载地址等统一配置聊天室历史记录拉取可以按类型筛选功能聊天室队列权限可配置聊天室更新用户信息后,断线重连进入聊天室时,相应信息依旧还在的功能Web
SDK
更新内容新增聊天室队列管理权限可配置聊天室历史记录拉取可以按类型筛选群管理员可以撤回其他人发的消息易盾反垃圾,支持对单条消息配置对应的反垃圾业务规则变更WebSocket链路若因网络状态不佳,悄悄被踢,将自动重连,不再由上层做处理WebSocket握手重连优化,清除实例接口下载地址请从以下官网地址下载:

摘要2018年2 月 9 日,Apache 基金会的邮件列表上发起了讨论是否接纳阿里的
Dubbo 项目进入 Apache
孵化器的投票。2018年2月15日,正式通过投票,顺利成为 Apache
基金会孵化项目。前言2018年2月9日,Apache
基金会的邮件列表上发起了讨论是否接纳阿里的Dubbo 项目进入 Apache
孵化器的投票。2018年2月15日,邮件列表显示,Dubbo 获得了 14
张赞成票,在无弃权和反对票的情况下,正式通过投票,顺利成为 Apache
基金会孵化项目。Apache开源孵化器Apache
的顶级项目往往都需要经过孵化器孵化,满足一系列质量要求之后才可毕业。2016
年 12 月 15 日,阿里巴巴曾宣布将移动开源项目 Weex 捐赠给 Apache
基金会开始孵化,目前尚未毕业。Dubbo 是否能正式成为 Apache
的顶级项目,还有一段路要走。社区的加入,能否让 Dubbo
的实用性再上一层楼,我们拭目以待。关于Dubbo说起 Dubbo
框架,可能很多后端开发者都有所了解,它是国内比较早的、影响较大的开源项目,包括阿里巴巴、京东、当当网、去哪儿网、网易考拉、微店等电商平台都有其成功应用案例。Dubbo
于 2011 年开源,之后就迅速成为了国内该类开源项目的佼佼者。可以想象,2011
年时,优秀的、可在生产环境使用的 RPC 框架很少,Dubbo
的出现迅速给人眼前一亮的感觉,而同时它又有阿里巴巴背书,所以也迅速收到了开发者的亲睐。Dubbo
目前在 GitHub 上有超过 16000 个 star 和超过 12000 的 fork
数,绝对是国内影响力最大的开源项目之一。但奇怪的是,在 2014 年 10 月 30
日发布 2.4.11 版本后,Dubbo 突然停止更新,当时社区一片哗然(其实是在
2012 年 10
月之后就基本停止了重要升级,改为阶段性维护)。具体原因现在也不得而知,知乎上也有一些讨论,包括团队调整、内部主推
HSF 等。不过可以确认的是,在 4
年前,国内企业对于开源的重视程度都远远没有今天高。而在官方停止更新 Dubbo
之后,当当网(Dubbox)、网易考拉(Dubbok)都有维护自己单独的分支,这也可以从另外一个侧面证明
Dubbo
确实应用到了这些企业的重点业务,并且规模不小。随着阿里巴巴对于开源的逐步重视,2017
年 9 月 7 日,Dubbo 悄悄的在 GitHub 发布了 2.5.4
版本。随后,没过多久,又迅速发布了 2.5.5、2.5.6、2.5.7 等版本。在 10
月举行的云栖大会上,阿里宣布 Dubbo
被列入集团重点维护开源项目,这也就意味着 Dubbo
起死回生,开始重新进入快车道。阿里巴巴为何重启Dubbo而对于为什么要重新启动维护
Dubbo,以及 Dubbo 和 HSF 的关系,Dubbo 未来的计划,当时聊聊架构也采访了
Dubbo
负责人、阿里巴巴中间件高级技术专家罗毅,感兴趣的读者可以点击阅读原文《阿里重启维护Dubbo了》。这次采访中,令我印象深刻的是罗毅提到了
Dubbo
的愿景,他说开源就阿里巴巴集团在技术层面赋能的重要领域,阿里巴巴中间件团队今后不仅要聆听社区的声音,及时修复问题,及时合并优秀的
pull request,还会力争将 Dubbo 打造成有国际影响力的 RPC
框架。国际影响力,让人一下子沸腾。而对于 Dubbo 和 Spring Cloud
的区别,罗毅也做了总结,一针见血:需要强调的是 Dubbo
未来的定位并不是要成为一个微服务的全面解决方案(Spring Cloud
是),而是专注在 RPC
领域,成为微服务生态体系中的一个重要组件。至于大家关注的微服务化衍生出的服务治理需求,我们会在
Dubbo
积极适配开源解决方案,甚至启动独立的开源项目予以支持。Dubbo的未来这一次,Dubbo
进入 Apache 孵化器。也就是说,Dubbo 将不再是阿里巴巴的
Dubbo,而是开源社区的,它未来的走向以及规则将会像其他的 Apache
项目一样。不过,从孵化项目到正式的开源项目,Dubbo
其实还有一段路要走。知乎上,昵称为二货的用户对这一流程做了详细解释,以下为摘录:Apache
项目有多个阶段,第一个阶段是进入孵化器。在进入孵化器前会有诸多审核流程,通过后进入
Apache Incubator。此时成员需要签一个协议,完成后获赠 Apache 账户(Apache
邮箱可以免费使用 intellij 哦,这也是 jetbrains
对开源贡献者的鼓励呐~)。在这个阶段会有 mentor 进行社区化指导,包括 PR
流程,包括 license 检查,包括 mail list
的回复,等等等。除了项目保持活跃外,还需要有外部
commiter。当项目在孵化器中持续一段时间满足毕业条件后便可以走正式毕业流程了。毕业后,项目移出
incubator,成为正式开源项目。项目更新流程不会有什么变化。另一种情况是项目失活,缺少社区支持与维护。那么就会被移出(不多见)。这里需要注意的是,社区活跃度是一个培养的过程。并不是说你一来就社区全是人的,这也正是孵化阶段的目的。最后,祝
Dubbo
能有一个更好的未来,就像其使命一样,成为有国际视野的顶级开源项目。同时,也祝各位开发者新年快乐,狗年旺旺旺!

相关文章