未发布 一体化建模仿真平台20-sim v4.6.3发布丨附下载 20-sim是一种机电一体化系统的建模和仿真程序。利用20-sim可以像绘制工程方案一样灵活地的键入模型。这些模型能用于仿真和分析多域动态系统的特性，也可以创建控制系统，甚至可以生成C代码并用于快速原型设计和HIL仿真。
【20-sim v4.6最新版点击下载】
一体化建模仿真平台20-sim v4.6.3发布。此版本是一个维护版本，主要修复了以下问题：
编辑器
修复：当“名称”文本不在矩形内时，无需重新调整图标中的矩形。
改进：重新调整矩形应考虑到网格。
修复：SVG相关内存泄漏。
修复：当通过单键开关替换多键接点后，将单个端口连接到多端口绑定元件时出现异常。
修复：带有掩码的库块可能会触发isRelease异常。
改进：模型>处理>警告/错误>“端口未使用”重命名为“电源端口未使用”，因为它不适用于信号端口。
运动配置文件编辑器：修复帮助按钮不可用的问题。
修复：全局参数的工具提示在其他子模型中使用时未显示描述性注释。
修复：在此库块的搜索操作后插入时，过滤器编辑器无法打开。
图标编辑器
界面编辑器
线性系统编辑器
3D动画编辑器
3D力学编辑器
Processing
修复：并非所有句法错误都会从全球关联编辑器报告给用户
修复：当“Optimize divisions”启用时，某些型号的处理可能会失败
修复：当按“保存”时，20-sim会尝试检查当前的子模型。这不应该完成，因为当前的子模型可能还没有完成。
Library
模拟器
脚本
修复：防止模拟期间更改子模型。
修复：包含“＆”的路径中的模型无法使用脚本打开。
改进：在xxsimSaveModel函数中接受斜杠语法。
Python：修复set_implementations（）不接受Python 3.x下的dict的问题。
Python：修复各种脚本问题。
Python：添加get_version（）函数（返回20-sim版本）
Octave：添加xxsimGetVersion（）函数（返回20-sim版本）
Octave：增加了Octave 4.2.0的支持（Windows，32位）
C代码生成
特点：C / C ++代码生成模板现在可以告诉20-sim这个模板支持哪些集成方法。支持在将来版本的模板中可变步长集成方法。
修复：使用两个反斜杠的字符串参数的C代码生成三个反斜杠而不是四个。
修复：在生成的子模型之外分配的全局字符串参数生成为空字符串。
文件
入门手册：改进各种更正和阐述。
参考手册：修复树中的函数名不能以capital开头的问题。
参考手册：删除Windows XP和X-file格式（不再支持）
文档生成：修复由于命名空间问题，XML文档生成的SVG文件无法在其他工具中打开的问题。
未发布 矢量图形引擎库VectorDraw Developer Framework 更新v7.7011.0.3 
VectorDraw Developer Framework（VDF）是一款构建2D、3D图形并用于应用程序可视化的矢量图形引擎库。有了VDF提供的功能，您可以轻松地创建、编辑、管理、输出、输入和打印2D和3D图形文件。该库还支持许多矢量和栅格输入和输出格式，包括本地PDF和SVG导出。
VectorDraw Developer Framework点击下载>>>
VectorDraw Developer Framework（VDF）v7.7011.0.3更新内容：
WebJS
新增需求
| 版本 | 需求 |
7.7011.0.1 | 70001006 支持webgl渲染模式的webgl图像 |
| 70001016 支持webgl节剪辑 |
| 70001019 支持使用scriptCommand hatch绘制阴影边框 |
| 70001024 使用鼠标进行缩放 |
| 70001029 实体选择回调 |
Converter
新增需求
| 版本 | 需求 |
| 7.7011.0.1 | 70001015 具有相同名称的vdXproperties导出不正确 |
漏洞
| 版本 | 需求 |
| 7.7011.0.1 | 70001009 DXF代理对象读取出错 |
| 70001020 某些DWF文件未正确打开 |
| 70001025 DGN Xrefs的问题 |
| 70001033 Layout paper未正确初始化 |
| 7.7011.0.2 | 70001040 SPLines在DWG中未正确导出 |
vdDXF
漏洞
| 版本 | 漏洞 |
| 7.7011.0.1 | 70001011 HANDLE类型的XProperty在DXF中未正确导出 |
Engine
新增需求
| 版本 | 需求 |
| 7.7011.0.1 | 70001008 改进ClearEraseItems方法的速度 |
| 70001012 MergeSelection方法用于传递对象的GUIDs |
| 70001027 虚拟机中的OpenGL问题 |
| 70001034 能够设置UCS图标字母的颜色 |
| 7.7011.0.2 | 70001036 外部引用对话框有一个支持路径按钮 |
漏洞
| 版本 | 漏洞 |
| 7.7011.0.1 | 70001007 当文本具有斜角时，EditText和AddText命令不会正确显示光标 |
| 70001010 点上的多点折线未正确显示 |
| 70001013 Inserts Inside Blocks层是处于ON状态时仍不可见 |
| 70001014 图层组和滤镜在删除后仍会保存到DXF中 |
| 70001017 图像在nonused Block中使用时会被删除 |
| 70001018 线型折线显示不正确 |
| 70001021 RenderToGraphics和RenderToDC会清除目标图形上下文的背景 |
| 70001022 尺寸对象未正确导入PDF |
| 70001026 在vdraw Idle中很少会随机出现exeption |
| 70001030 Bhatch命令为创建的polyhatch添加白色作为fillcolor |
| 70001031 用户选择部分文字的拉伸命令会出现错误 |
| 70001032 vdMtext对象没有对齐 |
| 7.7011.0.2 | 70001035 vdLayout DrawCCSAxis showOnOrigin参数无法正常工作 |
| 70001037 用户尝试打开特定文件后应用程序瘫痪 |
| 70001038 图像不能从EMF正确导入 |
| 70001039 Block名称不适用于DWG |
| 70001042 具有Shape段的LineTypes不能在3d中与ExcludeFromList Draw3DFlag正常显示 |
未发布 MailBee.NET Objects显示HTML/纯文本邮件教程（三）：在Web应用程序中显示 MailBee.NET Objects是一款为创建、发送、接收以及处理电子邮件而设计的健壮、功能丰富的.NET控件。几行代码便可为应用程序添加E-Mail支持，简单高效。具备“必需”以及独特的功能，这些控件帮助开发人员简单快速地将复杂的电子邮件功能添加到他们的应用程序中。
本文主要介绍了在Web应用程序中显示HTML/纯文本邮件的代码示例。目前MailBee.NET Objects在线订购享75折优惠正在进行中，欢迎您下载试用版进行运用！
由于Web应用程序在呈现HTML而不是纯文本的Web浏览器中运行，因此应将纯文本数据转换为HTML，以便在浏览器中查看此数据。这也适用于在HTML容器中渲染数据的桌面应用程序。
MailBee可以邮件解析期间自动将纯文本内容转换为HTML。为了调整邮件解析过程，MailMessage类提供了Parser属性。
C＃
MailMessage msg = pop.DownloadEntireMessage(1);
msg.Parser.PlainToHtmlMode = PlainToHtmlAutoConvert.IfNoHtml;
VB.NET
Dim msg As MailMessage = pop.DownloadEntireMessage(1)
msg.Parser.PlainToHtmlMode = PlainToHtmlAutoConvert.IfNoHtml
上面的节点从服务器中下载邮件，并让MailBee自动将邮件的纯文本转换为HTML（如果邮件还没有HTML版本）。因此，你将得到可以在ASP.NET应用程序中显示的HTML邮件，如下所示：
C＃
Response.Write(msg.BodyHtmlText);
VB.NET
Response.Write(msg.BodyHtmlText)
如果你还需要在HTML容器中显示邮件标头，你可以使用HeadersAsHtml属性替换邮件的所有标题中的“<”，“>”，“和”和“”字符，其HTML表示形式为：
C＃
msg.Parser.HeadersAsHtml = true;
Response.Write("From: " + msg.From.ToString());
VB.NET
msg.Parser.HeadersAsHtml = True
Response.Write("From: " + msg.From.ToString())
未发布 扫描识别工具Dynamic Web TWAIN使用教程：属性/方法/事件介绍 Dynamic Web TWAIN是一个专为Web应用程序设计的TWAIN扫描识别控件。你只需在TWAIN接口写几行代码，就可以用兼容TWAIN的扫描仪扫描文档或从数码相机/采集卡中获取图像。
本文为你介绍Dynamic Web TWAIN中属性/方法/事件的具体操作代码，欢迎收藏。
当正确实施后，Dynamic Web TWAIN将在页面加载后自动初始化。一旦初始化，你就可以像堆任何正常的JS对象一样控制它。您可以参考我们的在线API文档来查看Dynamic Web TWAIN的所有内置属性、方法和事件。
这里有三种使用Dynamic Web TWAIN的方法：
属性
属性用于在运行时从Dynamic Web TWAIN中获取或设置特定的值，例如Resolution、Duplex、IfShowUI等。
1 2 3 | /* Property */
/* Scan pages in 200 DPI */
DWObject.Resolution = 200;
|
方法
方法用于调用Dynamic Web TWAIN对象的内置函数，如AcquireImage、SaveAsJPEG、Rotate等。语法非常简单：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | // Method
///
<summary> /// Rotates the image of a specified index in buffer by a specified angle.
/// </summary>
///
<param name="sImageIndex" type="short" data-filtered="filtered">
specifies the index of image in buffer. The index is 0-based.
///
<param name="fAngle" type="float" data-filtered="filtered">
specifies the angle.
///
<param name="bKeepSize" type="bool" data-filtered="filtered">
specifies whether to keep the original size
///
<returns type="bool" data-filtered="filtered"></returns>
DWObject.Rotate(0, 45, false); // rotate the 1st image in the buffer by 45 degrees
|
事件
当达到某个触发点时触发事件。例如，OnMouseClick鼠标点击事件等。与属性和方法相比，事件是有点难度的。在这里我们再多谈一下。
处理事件
添加一个事件监听器
要添加事件监听器，可以使用内置方法RegisterEvent。请参考下面的示例代码：
1 2 3 4 5 6 7 8 9 10 11 12 13 | <script type="text/javascript" data-filtered="filtered">
Dynamsoft.WebTwainEnv.RegisterEvent('OnWebTwainReady', Dynamsoft_OnReady);
var DWObject;
/* OnWebTwainReady event fires as soon as Dynamic Web TWAIN is initialized and ready to be used. It is the best place to add event listeners */
function Dynamsoft_OnReady() {
DWObject = Dynamsoft.WebTwainEnv.GetWebTwain('dwtcontrolContainer');
DWObject.RegisterEvent("OnPostTransfer", Dynamsoft_OnPostTransfer);
}
function Dynamsoft_OnPostTransfer() {
/* This event OnPostTransfer will be triggered after a transfer ends. */
/* your code goes here*/
}
</script>
|
在上面的代码中，我们添加了JavaScript函数Dynamsoft_OnPostTransfer()作为事件OnPostTransfer的事件监听器。另外，你可以写这样的代码：
1 2 3 4 5 6 7 8 9 10 | <script type="text/javascript" data-filtered="filtered">
Dynamsoft.WebTwainEnv.RegisterEvent('OnWebTwainReady', Dynamsoft_OnReady);
var DWObject;
function Dynamsoft_OnReady() {
DWObject = Dynamsoft.WebTwainEnv.GetWebTwain('dwtcontrolContainer');
DWObject.RegisterEvent("OnPostTransfer", function() {
/* your code goes here*/
});
}
</script>
|
有参数的事件
一些事件具有参数。以OnMouseClick事件为例：
1 2 | /* sImageIndex is the index of the image you clicked on*/
OnMouseClick(short sImageIndex)
|
当您创建相应的JavaScript函数（AKA，事件侦听器）时，可以包含参数并在运行时进行检索。
1 2 3 | function DynamicWebTwain_OnMouseClick(index) {
CurrentImage.value = index + 1;
}
|
或者
1 2 3 | DWObject.RegisterEvent("OnPostTransfer", function(index) {
CurrentImage.value = index + 1;
});
|
特殊事件 -“OnWebTwainReady”
在所有的内置事件中，有一个特殊事件“OnWebTwainReady”。基本上这个事件在Dynamic Web TWAIN对象被初始化并准备好使用的时候触发。正如您在本文前面看到的那样，推荐使用它的方法是：
1 2 3 4 5 6 7 | <script type="text/javascript" data-filtered="filtered">
Dynamsoft.WebTwainEnv.RegisterEvent('OnWebTwainReady', Dynamsoft_OnReady);
var DWObject;
function Dynamsoft_OnReady() {
DWObject = Dynamsoft.WebTwainEnv.GetWebTwain('dwtcontrolContainer');
}
</script>
|
或者
1 2 3 4 5 | <script type="text/javascript" data-filtered="filtered">
Dynamsoft.WebTwainEnv.RegisterEvent('OnWebTwainReady', function() {
DWObject = Dynamsoft.WebTwainEnv.GetWebTwain('dwtcontrolContainer');
});
</script>
|
本次教程到此结束，希望能对Dynamic Web TWAIN的用户带来帮助，接下来还会有更多的相关教程，敬请期待！
未发布 GIS软件开发包Map Suite v10.0发布，支持Windows、Linux和macOS多平台 Map Suite 10.0新功能
核心功能支持Windows、Linux和macOS多平台。
所有Map Suite产品系列都共享核心API。
删除合并模块并将所需的程序集移动到特定程序包。
创建可在多平台（包括Windows、Linux和macOS）上运行的新产品中心。
Map Suite产品托管在NuGet服务器上，而不是Map Suite安装程序。
简化Map Suite许可策略。
按功能拆分MapSuiteCore 9.0程序集。允许将必要的程序集导入到这些项目中。
在Linux上支持ECW文件。
在Linux上支持MrSid和JPEG2000文件。
用于Map Suite产品的BareBone NuGet Package可以创建最小尺寸的应用程序。
用于Map Suite产品的Standard NuGet Package可以让用户更轻松的将现有的9.0项目转移到10.0版本上。
v10.0和v9.0之间的变化
我们努力使安装过程和版本维护变得更加容易，并将所有Map Suite产品重新打包到NuGet软件包中。开发人员可以选择在本地安装引用、通过使用Visual Studio的NuGet管理器进行管理或者为你的团队设置本地NuGet服务器。
更有效率
Map Suite产品可帮助开发人员更有效地创建GIS应用程序。将Map Suite组件运用到你的项目中并进行分享会让你的工作变得更加效率。
跨平台/便携式
在Map Suite 9.0之前，我们一直考虑支持像Linux、MacOS、Android、iOS这样的多平台。然而，基础结构阻止了我们的步伐。如果你已经是使用Map Suite产品的开发人员，你可能知道我们支持Windows（Wpf、WinForms ...）、iOS和Android平台，但在很长一段时间中这是比较困难的。想象这种情况：客户在Windows平台上报告MapSuiteCore中的错误。我们对它进行修复并测试。但这并不是全部的工作。我们还要向iOS和Android团队报告，要求他们解决相同的错误。这是基础结构方面的错误。我们有几个MapSuiteCore分支，它依赖于不同的框架。每次修复bug时，我们需要与其他平台同步。
现在，我们的目标是让Map Suite Core的源代码尽可能便携。借助分离MapSuiteCore的机会，我们可以将现有的功能转换为便携式。本质上来说各平台可以共享相同的源代码。
分离Map Suite Core
在Map Suite 9.0中，我们在名为“MapSuiteCore”和几个扩展的程序集中支持大部分功能。而其他产品则具有基础结构。当你启动项目时，你只能引用包含Map Suite所有功能的“MapSuiteCore”。这无法最小化你的项目。
我们决定按照功能来分离Map Suite Core，例如形状、层数、样式、符号等。你所知道的每个Map Suite功能都可能是一个单独的包。你可以选择性地使用项目所需的软件包，并将应用程序控制在最小。
更简单的试用许可证
认证和许可是NuGet软件包的一个缺点。不过，我们为非注册开发人员制定了一个新策略，你不用注册就可以在有限的时间内评估Map Suite产品。你只需打开Visual Studio，创建一个项目，打开NuGet管理器并输入“MapSuite”。它会返回给你Map Suite支持的全部功能列表。
PS：原始许可证仍与10.0兼容。
第一次运行Map Suite 9.0或更低版本样本的工作流程。
第一次运行Map Suite 10.0样本的工作流程。
更改命名空间
在Map Suite 9.0和以前版本中，命名空间主要由ThinkGeo.MapSuite.Core和版本命名空间两部分组成，如ThinkGeo.MapSuite.WebEdition。现在ThinkGeo.MapSuite.Core基于它的功能已经分离了，现在我们有：
ThinkGeo.MapSuite包含用于构建Map Suite应用程序的常用和基础类，如GeographyUnit、GeoCollection等。
ThinkGeo.MapSuite.Drawing包含绘图相关类，如GeoImage、GeoSolidBrush等。
ThinkGeo.MapSuite.Layers包含一些基础类，如Layer、FeatureLayer等。
ThinkGeo.MapSuite.Shapes包含几何相关类，如PlygonShape、LineShape等。
ThinkGeo.MapSuite.Styles包含用于构建地图样式的类，如AreaStyle、LineStyle等。
未发布 ReactOS：基于Windows的开源操作系统 ReactOS是一个免费开源的全新操作系统，其设计基于Windows，就像Linux基于Unix一样。ReactOS的外观和Windows类似，可以运行Windows软件和驱动，不过，该项目正在进行当中，可能尚无法完美兼容，最好的方法是在虚拟机上安装ReactOS，检查兼容性。
ReactOS使用X.Y.Z版本命名方案：X表示项目是否达到预期目标，Y表示大版本（关键特性和增强），Z表示小版本（Bug修复和一般开发）。第一个有文档记录的版本是0.0.7，发布于1998年7月。
作为开源项目，由于社区开发人员的数量不固定，所以ReactOS没有一个固定的路线图。不过，他们会尽量在二到六个月发布一个版本。0.4.0、0.5.0和1.0.0是当前设置的里程碑版本。0.4系列版本是最后的Alpha版本，从0.5系列版本开始，项目将进入Beta测试阶段，1.0及以上版本表明该项目已经可供日常使用了。
ReactOS 0.4.6已于近日发布。该版本向真正的硬件支持迈出了重要的一步。若干双启动问题得到了解决，分区管理的安全性得到了提高，可以避免分区列表结构的冲突。ReactOS Loader现在可以加载自定义内核和HAL了。
在0.4.6中，打印子系统尚不成熟，但Colin Finck已经实现了大量新的API，并修复了一些自动化测试中暴露出的Bug。
在驱动方面，Pierre Schweitzer为其增加了NFS驱动程序，并开始实现RDBSS和RXCE，将来还会支持SMB。Sylvain Petreolle为其引入了数字电视调谐器驱动。UDFS、CDFS、SCSI和HDAUDBUS中的若干Bug也得到了修复。
在兼容性方面，0.4.6引入了一个shim引擎，作为新应用程序兼容框架的一部分。在这个版本中，该引擎默认关闭，可以通过ReactOS注册表启用。该版本还包含一个专门的NTDLL库，可以为比较新的软件提供一些它们需要的NTDLL Vista+函数。
ReactOS 0.4.6还改进了用户体验，并修复了多个内存管理、ntoskrnl和文件系统的Bug，变得更加稳定。
未发布 百度正式开源其RPC框架brpc 9月14日，百度正式在GitHub上基于Apache 2.0协议开源了其RPC框架brpc。brpc是一个基于protobuf接口的RPC框架，在百度内部称为“baidu-rpc”，它囊括了百度内部所有RPC协议，并支持多种第三方协议，从目前的性能测试数据来看，brpc的性能领跑于其他同类RPC产品。
brpc开发于2014年，主要使用的语言是C++和Java，是百度内部使用最为广泛的RPC框架，它经受了高并发高负载的生产环境验证，并支撑了百度内部大约75万个同时在线的实例。据了解，百度内部曾有多款RPC框架，甚至在2014年时还开源过另外一款RPC框架sofa-pbrpc。那brpc是在什么样的背景下诞生的？它有什么样的优势？又为何要开源？就这些问题，InfoQ记者采访了brpc负责人戈君。
Q：谈谈brpc的一些基本情况？什么时候开始研发的？经过了怎么样的迭代和升级？目前在内部应用情况如何？
戈君：brpc于2014年创建，在百度内部称为“baidu-rpc”。到目前为止，brpc一共进行了3000次左右的改动，现在仍在持续优化中，百度内的wiki上可以查询到每次改动的描述。brpc的主要语言是C++和Java，对其他语言的支持主要是通过包装C++版本，比如brpc的Python版包含C++版的大部分功能。
brpc目前支撑百度内部大约75万个同时在线的实例（不含client），超过500种服务（去年的统计，现在已不统计这类数据）。Hadoop、Table、Mola（另一种广泛使用的存储）、高性能计算、模型训练、大量的在线检索服务都使用了brpc。brpc第一次统一了百度内分布式系统和业务线的通信框架。
Q：为什么百度当时要研发brpc？
戈君：我们在实践中意识到，RPC作为最基础的通信组件，当时的百度已经不领先了。我当时的经理刘炀曾是Google的工程师，非常重视基础架构的建设，也愿意在这个方向投入资源。
我们在内部会更加深入地讨论这些问题。“好用”有时看起来很主观，但其实还是有据可循的，它的关键点是能不能真正地提高用户的效率：开发、调试、维护都要考虑到，如果用户效率真的被提高了，用户会想着你的，靠吹嘘或政令推广的东西得不了人心。我们创建brpc的初衷是解决百度业务所面临的实际挑战，同时也希望成为百度同学最喜爱的工具，哪怕离开百度也会怀念brpc。我们希望在提供了一个好用框架的同时，也展现了一种工作方法：注释怎么写，日志怎么打，ChangeLog怎么写，版本怎么发布，文档怎么组织，甚至对未来不在百度的同学的工作也有帮助，所以从这点来说brpc从一开始就是拥抱开源的。事实上，我们在口碑上做得还不错，brpc的wiki可能是百度内被点赞最多的内容之一。
Q：与其他的一些开源的RPC框架相比，brpc的优势是什么？
戈君：brpc主打的是深度和易用性。一方面我们没有精力像gRPC那样摊大饼，什么都做。另一方面我们也注意到gRPC（包括更早的Thrift）的深度和易用性并不够。技术方面的东西就是这样，看示例程序，文档非常牛逼，但实战中可能就是另一回事了，为什么各个公司都要造自己的轮子，一个隐藏原因就是表面高大上的东西在一些细节上让你无法忍受。
RPC真正的痛点是什么？是可靠性、易用性和定位问题的便利性。服务中不要出现不可解释的长尾，程序的可变项要尽量少，各种诡异问题要有工具支持快速排查。而这些在目前开源的RPC框架中做的并不好，它们大多看着很牛，但就是无法在自己组织中推广开来。回到前面那三点，brpc是如何做的呢？
- 可靠性。这一方面是代码质量问题，通过为brpc团队设立很高的招聘门槛，以及在团队中深入的技术讨论，我们确保了稳固的代码基础。另一个问题是长尾问题，这是设计问题，brpc其实包含了很多模块，其中的bthread是一个M:N线程库，就是为了更好地提高并发避免阻塞。brpc中的读和写都是wait-free的，这是最高程度的并发。技术细节请点击链接查看。
- 易用性。有种设计是什么选择都做成选项丢给用户，号称功能都有，但一旦出问题，则是用户“配置错了”。而且这样用户还非常依赖开发团队，没有开发团队的支持基本用不了，开发团队有足够的理由扩充团队。这么做其实非常不负责任，用户面对海量的选项也很难受。brpc对于增加选项非常谨慎，框架能自己做判断的绝不扔给用户，所有用户选项都有最合理的默认值，不设也能用。我们认为这对用户体验来说非常重要。
- 定位问题的便利性。这点其它开源框架目前做的都不好，正常使用是可以的，但出问题就麻烦了。这个问题在百度内部其实也很严重，brpc之前用户排查问题都要拉RPC同学一起排查，RPC框架对用户是个黑盒，用户根本不知道里面发生了什么。按我们的经验，基本每天都有几个用户在群里问server卡顿，client超时之类的问题，排查问题是常态，人手必然不够。时间长了用户就觉得你这个框架各种问题，人还拽的不行很少回他们消息。brpc的解决办法是给server内加入各种HTTP接口的内置服务，通过这些服务，用户可以很快看到server的延时、错误、连接、跟踪某个RPC、CPU热点、内存分配、锁竞争等信息，用户还可以使用bvar来自定义各类统计信息，并在百度的运维平台NOAH上汇总。这样大部分问题用户可以自助解决。其实我们去看也是看这些，只是会更加专业。内置服务的具体说明可以看这里。
Q：作为公司内部的RPC框架，在服务治理方面有什么考虑？
戈君：百度内部RPC使用非常广泛，基本都是RPC调用，一些产品线还会通过local RPC隔离工程框架和策略代码。这么多年下来，服务周边的系统也比较全面了：编译是BCLOUD，发布是Agile，服务注册和发现是BNS，认证是Giano，监控和运维是NOAH。在百度内部，brpc和这些系统做了比较紧密的绑定，用户体验是一站式的。虽然在开源版本中，这些结合大都删掉了，但用户可以根据自己组织中的基础设施来进行定制：交互协议，名字服务，负载均衡算法都可以定制。对于其中一些特别通用的，我们希望用户反馈到开源版本中来以方便所有人。
Q：之前百度还开源过sofa-pbrpc，brpc与它的区别是什么？
戈君：sofa-pbrpc也是百度开发的一个比较早期的RPC框架，属于sofa编程框架的一部分，在搜索有应用。brpc相比sofa-pbrpc有如下优点:
- 对协议的抽象更一般化，并统一了全百度的通信架构。bprc能容纳非常多的协议，基于Protobuf的，基于HTTP的，百度内的nshead/mcpack，开源的Redis/Memcached，甚至RTMP/FLV/HLS直播协议，brpc能逐渐地嵌入现有系统，而不需要彻底重构，但sofa-pbrpc则不具备扩展协议的能力。类似的，sofa-pbrpc也无法定制负载均衡算法，brpc默认提供round-robin、随机、一致性哈希，Locality-aware（局部性感知）四种算法，用户还能定制。
- 多线程质量更好。多线程编程是非常困难的，看起来简单的RPC遍布多线程陷阱，比如处理超时的代码可能在RPC还没发出去时就运行了；发送函数还没结束，处理回复的回调就被运行了；一个回复还在被处理另一个回复回来了，诸如此类。另外，一个异步RPC的回调里发起一个同步RPC会发生什么，带着锁做同步RPC会发生什么。这些问题我们都不能在sofa-pbrpc中找到满意的答案。
- 完备的调试和运维支持。解决这个问题的本质还在可扩展性，你如何让用户参与进来定制他们感兴趣的指标，为此我们设计了bvar，让用户能用比原子变量代价还小的方式自由地定制各种指标，用户能在浏览器上看到指标的变化曲线，或在运维平台NOAH看到汇总的监控数据。brpc还加入了大量内置服务方便用户调试程序，查看连接，在线修改gflags，追踪RPC，分析CPU热点，内存分配，锁竞争等一应俱全。
无需讳言，brpc在诞生之初和sofa-pbrpc在百度内部是有竞争关系的，但就像其他地方一样，这种竞争带来了活力。类似的，brpc和其他已经开源的RPC框架也是良性的竞争关系，在比拼谁能真正提高用户效率的过程中共同进步。每个用户都可以去对比代码、文档质量，接口设计，易用程度，扩展能力等，投出自己的一票。
Q：谈谈brpc的整体架构？
戈君：技术栈无外乎是从传输层垒到应用层，就略过不讲了，具体可以去看下开源出来的文档。brpc在架构上强调“在不牺牲易用性的前提下增强可扩展性”，比如brpc支持非常多的协议，在百度内部一个brpc server同端口可以支持二十几种协议，这对于服务的平滑迁移就非常好用。
Client端的协议也非常多，用户用brpc和bthread用得很爽，所以希望我们最好能统一所有的客户端，像对Redis和Memcached的客户端支持也是在这个背景下做的，这两个客户端比官方Client好用多了，感兴趣的读者可以去尝试一下。但这么多协议的配置非常简单，填个字符串就行了，比如HTTP就是把ChannelOptions.protocol设为“http”，Redis就是“redis”。Server端甚至不用设，它会自动判断每个client的协议，怎么做到的开源文档里也有。
名字服务、负载均衡也都可以定制。但为了对用户负责，我们也不鼓励“太自由”的定制，比如一点点需求的变化就要搞个新的，这时更需要想清楚本质区别是什么。这个事情我们在百度内的支持群里每天都在做，我们是开放的”乙方”，但我们也是严厉的”乙方”。
Q：brpc的性能如何？这么高的性能是怎么做到的？
戈君：性能是我们非常看中的一点，它和用户体验也是紧密联系的。好用但性能不行，或不好用但性能很牛，用户会很难受，我们不希望用户纠结。从另一个角度来看，在推广初期，我们要说服产品线用brpc靠什么？最直观的就是性能提升。而且这儿的性能不能停留在benchmark的图片上，而是能在真实应用中体现出来。开放出来的案例文档中或多或少都包含了性能提升，具体如下：
- 百度地图API入口
- 联盟DSP
- ELF学习框架
- 云平台代理服务
Q：为什么要将brpc开源？接下来在开源项目的迭代方面有什么计划吗？
戈君：因为马上还有不少依赖RPC的百度系统要开源啊。RPC作为最基础的组件，开源不仅仅是为了自身，也是为其它开源项目铺路，比如说我们马上还会开源基于brpc的RAFT库，搭建高可用分布式系统非常方便；以及使用brpc的bigflow，让流式计算变得很顺手。这些年百度对开源的认识也在不断加深，开源看似曝光了百度的核心技术，但带来的生态影响力更重要。从Apollo、PaddlePaddle开始，百度真的开始拥抱开源了。brpc的开源版和内部版很接近，只是去掉了对百度内部独有的一些基础设施的支持，我们在内网写的深入分析RPC技术细节的文档也都一并开源了，后续也会及时推送改动，请大家放心。这是一个活项目，不会拉个开源分支就不管了。
查看更多资讯>>>
沪公网安备31011202009668号 | 沪ICP备13020027号-2