这是奥尔良团队的来宾帖子。 Orleans是用于使用.NET构建分布式应用程序的跨平台框架。 有关更多信息,请参见https://github.com/dotnet/orleans 。我们很高兴宣布Orleans 3.0版本。 自Orleans 2.0以来,进行了大量改进和修复,并提供了一些新功能。 这些变化是由许多人在广泛的场景和环境中在生产中运行基于Orleans的应用程序的经验所驱动的,以及全球Orleans社区的才智和激情,他们始终致力于使代码库更好,更快,更多。灵活。 BIG非常感谢以各种方式为该版本做出贡献的所有人!

自奥尔良2.0以来的重大变化
奥尔良2.0于18个月前发布,此后奥尔良取得了长足的进步。 自2.0版以来的一些标题更改是:
- 分布式ACID事务-无论状态存储在何处,多个谷物都可以加入事务
- 一个新的调度程序,仅在某些情况下,其性能就提高了30%以上
- 基于Roslyn代码分析的新代码生成器
- 重写集群成员资格以提高恢复速度
- 共同托管支持
以及许多其他改进和修复。
自开发Orleans 2.0以来,该团队与.NET团队密切协作,建立了一个实现或集成某些功能(例如通用主机,命名选项)的良性循环,然后才准备将这些功能纳入.NET。核心版本,“在上游”提供反馈和改进,在更高版本中,切换到.NET版本附带的最终实现。 在Orleans 3.0的开发过程中,这一周期一直持续着,直到Orleans 3.0.0-beta1最终将其作为.NET 3.0的一部分使用之前,都使用了基岩代码。 同样,在TCP套接字连接上对TLS的支持已作为Orleans 3.0的一部分实现,并打算成为.NET Core未来版本的一部分。 我们本着开放源代码的精神,将这种持续的合作视为对更大的.NET生态系统的贡献。
用ASP.NET Bedrock替换网络层
一段时间以来,无论
是社区还是内部合作伙伴,对保护
TLS通讯安全的支持一直是一个主要问题。 在3.0版本中,我们引入了TLS支持,可通过
Microsoft.Orleans.Connections.Security包获得该支持。 有关更多信息,请参见
TransportLayerSecurity示例 。
由于如何实现Orleans早期版本中的网络层,实现TLS支持是一项艰巨的任务:无法轻松地使其适应于使用
SslStream
,后者是实现TLS的最常见方法。 以TLS为动力,我们踏上了重写奥尔良网络层的旅程。
奥尔良3.0取代了整个网络层,该层基于ASP.NET团队的计划
Project Rock之上。 Bedrock的目标是帮助开发人员构建快速而强大的网络客户端和服务器。
ASP.NET团队和Orleans团队共同设计支持网络客户端和服务器,与传输无关的抽象,并且可以使用中间件进行自定义。 这些抽象使我们可以通过配置更改网络传输,而无需修改内部或特定于奥尔良的联网代码。 奥尔良的TLS支持作为基岩中间件实现,我们的目的是使之通用,以便可以与.NET生态系统中的其他人共享。
尽管这项工作的推动力是启用TLS支持,但在夜间负载测试中,我们平均将吞吐量提高了约30%。
网络层重写还涉及依赖于
MemoryPool<byte>
替换我们的自定义缓冲池,并且在进行此更改时,序列化现在更多地利用了
Span<T>
。 以前依赖于通过调用
BlockingCollection<T>
专用线程进行阻止的某些代码路径现在正在使用
Channel<T>
异步传递消息。 这样可以减少专用线程的数量,从而将工作移至.NET线程池。
自最初发布以来,奥尔良的核心线协议一直保持不变。 在Orleans 3.0中,我们增加了对通过协议协商逐步升级网络协议的支持。 Orleans 3.0中添加的协议协商支持可实现将来的增强功能,例如自定义核心序列化程序,同时保持向后兼容性。 新网络协议的一个好处是支持全双工筒仓到筒仓的连接,而不是以前在筒仓之间建立的单工连接对。 可以通过
ConnectionOptions.ProtocolVersion
配置协议版本。
通过通用主机共同托管
现在,通过
.NET Generic Host可以比以前更轻松地在同一过程中与其他框架(如ASP.NET Core)共同托管Orleans。
这是使用
UseOrleans
将Orleans与ASP.NET Core一起添加到主机的
UseOrleans
:
var host = new HostBuilder() .ConfigureWebHostDefaults(webBuilder => {
使用通用主机构建器,奥尔良将与其他托管服务共享服务提供商。 这将使这些服务可以访问奥尔良。 例如,开发人员可以将
IClusterClient
或
IGrainFactory
注入ASP.NET Core MVC控制器,并直接从其MVC应用程序调用粒度。
此功能可用于简化部署拓扑或向现有应用程序添加其他功能。 一些团队在内部使用联合托管,通过
ASP.NET Core Health Checks将
Kubernetes活跃性和就绪性探针添加到他们的奥尔良孤岛。
可靠性提高
现在,由于扩展了闲聊,群集从故障中恢复的速度更快。 在以前的奥尔良版本中,孤岛会向其他孤岛发送成员闲话消息,指示他们更新成员信息。 八卦消息现在包括集群成员身份的版本化,不变的快照。 这样可以缩短筒仓加入或离开集群后的收敛时间(例如,在升级,扩展或失败后),并减轻共享成员存储上的争用,从而加快集群转换的速度。 故障检测也得到了改进,具有更多的诊断消息和改进功能以确保更快,更准确的检测。 故障检测涉及群集中的孤岛,这些孤岛相互协作监视,每个孤岛向其他孤岛的子集发送定期运行状况探测。 孤岛和客户端现在还主动断开与已宣布已失效的孤岛的连接,它们将拒绝与此类孤岛的连接。
现在,可以更一致地处理消息错误,从而将提示错误传播回调用者。 这有助于开发人员更快地发现错误。 例如,当消息无法完全序列化或反序列化时,详细的异常将传播回原始调用方。
增强的可扩展性
流现在可以具有自定义数据适配器,从而允许它们以任何格式摄取数据。 这使开发人员可以更好地控制流项目在存储中的表示方式。 它还使流提供者可以控制如何写入数据,从而允许流与旧式系统和/或非奥尔良服务集成。
谷物扩展允许通过在新组件上附加自己的通信接口,从而在运行时向谷物添加其他行为。 例如,奥尔良交易使用谷物扩展来向用户透明地向谷物添加交易生命周期方法,例如
Prepare ,
Commit和
Abort 。 谷物扩展现在也可用于谷物服务和系统目标。
现在,自定义事务状态可以声明其在事务中能够扮演的角色。 例如,将事务生命周期事件写入服务总线队列的事务状态实现不能满足事务管理器的职责,因为它是只写的。
预定义的放置策略现在可以公开访问,因此在配置期间可以替换任何放置控制器。
共同努力
现在Orleans 3.0即将上市,我们将注意力转向将来的版本-我们有一些令人兴奋的计划! 快来加入我们在
GitHub和
Gitter上热情友好的社区,帮助我们实现这些计划。
奥尔良队