（前段时间封闭式开发完了一个项目，最近才有时间继续更新GG的后续版本，对那些关注GG的朋友来说，真的是很抱歉。）GG的前面几个版本开发了一些比较高级的功能，像视频聊天、远程桌面、文件传送、远程磁盘等，但是，有一些基础且必需的功能一直未实现，比如注册、添加好友、加入群、群聊天等等。经常有朋友留言问这些功能要怎么做，GG3.0终于可以给出一个答案了。
先提醒一下，GG3.0中这些基础功能的实现方式是比较粗糙的，我还没有时间深入考虑性能、缓存等问题（源码中我以“建议”的字样标注了需要优化的地方），后续版本，我会将它们一一优化。由于长时间未更新，迫不及待地先放个版本出来给大家参考。
一.GG V3.0 新增功能展现
（1）注册新帐号。
（2）添加好友（包括：通知对方、好友上下线通知）。
（3）加入群（包括：通知其它群友、群友上下线通知）。
（4）群聊天。
（5）以前版本的帐号只能为数字（就像QQ一样），但是，3.0及以后版本，帐号中可以包含字母。
废话不多说，还是先上图。
注册：
添加好友：
加入群：
群聊天：
二.实现思路
虽然提供了源代码，但是，我还是想将主要的思路列一下，这样，大家理解起源码来，会节省更多的时间。
1.虚拟数据库
（1）为了部署测试更简单，GG没有采用真实的物理数据库，而是在内存中虚拟了一个数据库（即服务端的VirtualDB类），用于存储用户注册信息、好友关系、群信息等。
（2）GG内置了几个用户：10000、10001、10002、10003、10004，它们的登录密码都是"1"。
（3）GG内置的这几个用户之间都是好友关系。
（4）GG内置了两个群：G001、G002。G001群包含所有内置测试用户，G002群包含10000和10001两个用户。
（5）上述的这些内置信息，在VirtualDB类的构造函数中设定。
2.服务端主要变更
（1）RegisterService：服务端发布了一个Remoting服务RegisterService，用于提供注册服务。由于注册之前，用户帐号还不存在，所以，不能通过ESFramework来实现。
（2）FriendsManager：服务端增加了FriendsManager类，以提供好友关系信息。
（3）GroupManager：服务端增加了GroupManager类，以提供群/组的信息。
（4）BasicHandler：服务端修改了BasicHandler类的实现，以验证客户端登录的用户帐号密码。
（5）CustomizeHandler：服务端修改了CustomizeHandler的实现，使之可以处理来自客户端的各种请求消息（如加入群、加好友等请求）。
3.客户端主要变更
（1）增加RegisterForm、AddFriendForm、JoinGroupForm、GroupChatForm四个窗体分别用于注册、添加好友、加入群、群聊天。
（2）增加GlobalUserCache类，用于缓存所有的好友信息。
（3）客户端接收到的所有消息都是在MainFormPartial.cs文件中处理的，包括广播消息（如群聊）。
（4）用户信息使用User类封装（位于GG.Core项目的Entity.cs文件中）。
三.GG V3.0 源码下载
关于GG的最新全貌介绍，我单独写了一篇文章，作为汇总，可参见 可在广域网部署运行的QQ高仿版 -- GG2013概要。
欢迎和我探讨关于GG2013的一切，我的QQ：2027224508，多多交流！
大家有什么问题和建议，可以留言，也可以发送email到我邮箱：ggim2013@163.com。
如果你觉得还不错，请粉我，顺便再顶一下啊，呵呵
本文链接：可在广域网部署运行的QQ高仿版 -- GG叽叽V3.0，完善基础功能（源码），转载请注明。
欢迎转载，转载请注明出处，徽沪一郎。
楔子
源码阅读是一件非常容易的事，也是一件非常难的事。容易的是代码就在那里，一打开就可以看到。难的是要通过代码明白作者当初为什么要这样设计，设计之初要解决的主要问题是什么。
在对Spark的源码进行具体的走读之前，如果想要快速对Spark的有一个整体性的认识，阅读Matei Zaharia做的Spark论文是一个非常不错的选择。
在阅读该论文的基础之上，再结合Spark作者在2012 Developer Meetup上做的演讲Introduction to Spark Internals，那么对于Spark的内部实现会有一个比较大概的了解。
有了上述的两篇文章奠定基础之后，再来进行源码阅读，那么就会知道分析的重点及难点。
基本概念(Basic Concepts)
RDD - resillient distributed dataset 弹性分布式数据集
Operation - 作用于RDD的各种操作分为transformation和action
Job - 作业，一个JOB包含多个RDD及作用于相应RDD上的各种operation
Stage - 一个作业分为多个阶段
Partition - 数据分区， 一个RDD中的数据可以分成多个不同的区
DAG - Directed Acycle graph, 有向无环图，反应RDD之间的依赖关系
Narrow dependency - 窄依赖，子RDD依赖于父RDD中固定的data partition
Wide Dependency - 宽依赖，子RDD对父RDD中的所有data partition都有依赖
Caching Managenment -- 缓存管理，对RDD的中间计算结果进行缓存管理以加快整体的处理速度
编程模型(Programming Model)
RDD是只读的数据分区集合，注意是数据集。
作用于RDD上的Operation分为transformantion和action。 经Transformation处理之后，数据集中的内容会发生更改，由数据集A转换成为数据集B；而经Action处理之后，数据集中的内容会被归约为一个具体的数值。
只有当RDD上有action时，该RDD及其父RDD上的所有operation才会被提交到cluster中真正的被执行。
从代码到动态运行，涉及到的组件如下图所示。
没有评论:
发表评论