（开场白）
大家好，很高兴在这里分享。
在千聊直播上组织培训，公司范围内，这可能是第一次，
在这类时髦的直播app上做培训，对我是第一次。
大家当中，可能不少也是第一次使用这类直播应用。
很有新鲜感。
让我们开始第一次吧。
ok，先上图。
图（1）
大家知道，godu有2个对外接口： telnet 和 api。
（单从服务侧看，其实只有1个telnet接口，api，是对它做了一层封装。）
这个工具，原本是我开发 api 组件的副产品。
不少同事知道，godu的后台服务是java写的，
而api组件却有3个语言版本，分别用来适配不同语言开发的上层应用。
其中，java 版和 c# 版api，分别由北京通用、西安激活产品线开发；
c++ 版本，由广东本地提供，为了适配本地一个古老的应用。
在开发这个c++版api过程中，我做了一个简易的客户端来调测这个组件。
这个简易的客户端就是这个工具的雏形，
后来逐步发展，成为godu管理员的维护工具。
以上，是这个工具的产生背景的一点介绍。
下面，我们首先看看整个godu在网管里的定位。
图（2）
简单来说，godu是一个底层服务，为上层应用提供访问网元指令接口的通道。
图上是设想到的会用到godu的系统。
目前在广东，实际用到godu的应用，有：操作维护终端、智能巡检、智能预处理、局数据采集、还有本地一些特色应用。
统一采集里的指令采集部分据说也支持godu3，本地还没用——其他省可能有在用的。
另外，广东godu的telnet接口，目前有直接开放给第3方使用：有其他的网管开发厂商、也有局方自己开发的系统。
有意思的是，局方要求另一开发厂商（东信）按照godu的telnet接口，
重构他们的指令平台，对外提供和godu一样的接口。
最近，局方提一个需求，要我们就通过那个厂商的指令平台，去访问数通设备。
我们设计出到一个方案，把godu对接到对方的指令平台，
穿越2个平台访问网元，整个方案不用改代码，完全通过配置方式来实现。
如果有某个省有类似需求，可以下面聊。
接下来，看godu的系统组成。
图（3）
简单来说，api组件之外，系统包括1个核心服务、1个资源服务、1个轻量级的hsql数据库、1个配置站点。另有，还有1个资源同步服务，因为godu建有自己的资源模型，需要把网管资源库或其他资源数据同步进来使用，如果有这个自动同步机制，资源这块就是免维护的——意味着，你不用再去操心每个网元的ip这类具体资源数据。我了解到，不少部署godu3的省份，资源的自动同步这块并没有完全实现。有手工准备资源数据，导入godu资源库的。不管是自动同步还是手工导入，godu只使用资源数据。资源数据的维护，在godu系统之外进行。
回到第3张图。
业务配置和资源数据都保存在数据库。
资源服务，会加载数据库里的所有数据，重新组织，可以说是个内存数据库。
核心服务，接受网元连接请求，从资源服务查询到登录网元所需要的信息，主要有4种：
其中的2种，登录脚本和退出脚本，核心服务直接用来 建立和断开网元侧的会话，
另外的2种，指令执行结果判定规则和中间指令规则，核心服务本身并不使用，而是传递给api组件处理——这是godu3设计上非常关键的一点：
使得api不用访问数据库，就能拿到集中配置的业务规则——这是设计上一种解耦处理。
接下来，看godu管理员，要做哪些事情。
图（4）
在图中列出的维护范围中，我认为，godu管理员最重要的工作，是管理好连接方式。
连接方式，是godu3业务模型里最为核心的一个概念。
每类网元，如爱立信eNodeB，华为MME，对外都有一个统一的访问方式——它实际上是网元厂家提供的北向接口。
一个连接方式就定义这样一类北向指令接口，相关的的配置项主要有4个：
登录脚本模版、退出脚本模版、指令执行结果判定规则、中间指令规则。
和godu2比较：2是面向网元的配置，3是面向指令接口的配置
——这是两个版本最大的区别。
对godu3，只要厂家北向接口不变，网元数量增加也好、网元ip等资源变更也好，连接方式配置不需要动。
广东的godu3，目前支持的网元，有近20w个，连接方式120个。
这意味着，我只要维护好这120套配置，原则上就能保证20w网元连接畅通。
而godu2，20w个网元，至少要维护20w套网元配置，是可怕的事情。
同时，也要注意到，对godu3，一旦某个连接方式的配置有问题，就会影响到一批网元的连接，可能影响几个，也可能是几w个。
所以说，对godu3的业务配置而言，网元数量不再是关注的重点，
如何确保连接方式的配置质量——才是管理员的工作重心所在。
接下来，看godu管理员面临的2类问题。
图（5）
这2类问题，也就是这个工具的应用场景。
第1个场景，当有新类型网元接入，并且带来一种新的指令接口类型时，相应的，需要定义一个新的连接方式。问题是，如何验证该连接方式各配置项的正确性、完整性？
登录脚本、退出脚本，在核心服务侧处理，crt上直接连核心服务的telnet接口，登录一个网元，就可以验证。
但指令执行结果判定规则、中间指令规则，在api组件侧处理，必须拿能调用api组件的应用来检验。这个时候，这个工具就派上用场，它有对各配置参数，全面的、针对性的测试。
第2个场景，当有大量新网元接入，或网元侧割接导致有大的资源调整时，需要大批量检查网元的可连接性，以此检测路由、帐号、ip等资源的有效性。其实第2个场景也涵盖了第1个场景，当新类型网元数量较多的情况下，也需要批量检查。
下面，来看这个工具的业务规则验证界面。
图（6）
界面左侧，网元报文窗。右侧上部，控制参数，下部，状态显示。
首先登录上一个目标网元。
指令执行结果判定规则，在执行测试指令后，通过右下部的【执行状态】来验证。
中间指令规则，在执行一个能产生中间指令的测试指令后，在报文窗验证。
另外，控制参数里的模块、临时帐号，这个是核心服务的接口，操作维护终端有用到，这里也可以验证。
控制参数里的指定结束符和指定超时时间，这个属于api提供的接口，好像只有智能巡检配置里用到，在这里也可以验证，同样是通过状态显示里的【执行状态】。
接下来，看批量连接网元界面。
图（7）
界面左侧，是要检测的网元的列表，把网元名分行复制进去。
点击开始按钮，就依次连接网元，成功的和失败的分开放到右侧上下2个网元列表。
连接过程中，一旦当前网元有结论，就断开该网元的连接，继续下一个，这样保证工具同时只占一个连接，不会影响到godu的负荷。
连接过程支持暂停，也支持中断。
最终的结果可以导出到文件中查看。
图上有个实例。
另外，检测网元列表右上有个小按钮，里面可以临时指定godu服务，
如果当地部署了多套godu，这个就有用，可以切换到每个godu上去检测。
最后来看看这个工具的部署。
图（8）
部署最容易介绍。
复制工具目录，注册那个c++版api组件，配置一下godu服务的信息，就能使用。
目录里，有这个工具的使用说明。
（结束语）
内容基本完了，总结一下：
今天讲的可能有点头重脚轻。
重头是godu3本身一些设计理念的介绍，对这个工具的使用倒是轻描带过。
我觉得，这个工具功能上足够简单，的确没什么好讲的。
关键是理解它背后的东西，这样才能更好的使用它。
好了，今天这个培训的内容到此结束，谢谢大家。
下面是讨论、问答时间。
