2014-08-17 03:47:49

之前预告了要讲讲SDN的，后来发生了若干次博客荒芜事件。。最后不了了之。其实我的内心也是很想写博客的，每次想写的时候发现博客没法上传图片就停下来了。。 昨天狠下心终于用阿里云的OSS解决了博客上传图片的问题。可以看到图片的链接已经是华丽丽的aliyuncs.com

——题记

恩，去年夏天实习完后，就不得不进入了毕设阶段。毕设的老师选的是大二的《局域网和城域网》这门课的任课老师。

简单交流之后，就确定了我们的关系。呵呵呵。

然后他告诉我，我可以去看看NOX控制器。本来在这方面没有啥经验，听到XXX控制器感觉瞬间高大上。实习了一个暑假的Java结果又要用C++来做毕设，心里也比较呵呵。不过觉得也是锻炼机会，就接手了。

其实在那个时候我对交换机这一块完全没接触过（虽然自己各种折腾家里的路由器），我还在想SDN和CDN之间是不是有什么关系呢。。。蛤哈。。

于是，我与SDN的故事就这么开始了。

首先，不谦虚地，我说说传统交换 机吧。传统交换机分为两层：控制层和转发层（或者你可以说是控制面和数据面）

恩，多图杀猫。。。。。

就像图上这样。。

而SDN做了个什么事情呢？

答：就是把控制层抽了出来，使得多台交换机被一个控制层来控制。这样，只需要更改软件定义的控制层就可以在不更改硬件的情况下重写整个网络。再把功能抽成一个个的App（或者叫组件/component）实现自由扩展。

这就是SDN主要做了的事情。

SDN以控制层为中心，抽象出两个接口，所谓的“南向接口”和“北向接口”，意思就是字面意思。一个对应用，一个对交换机。

继续上图。

说到SDN就难免谈到OpenFlow。

如果说SDN是接口的话，OpenFlow就是这个接口的一种实现。OpenFlow就是SDN南向接口的实现。打通控制器和硬件之间的路。

控制器这里我们使用的是NOX，其实基于Java的FloodLight估计也差不多。

而北向接口的实现，自然我就只用过我们选的NOX控制器的组件接口了。。

OK，背景介绍到这里，我们进入正题

OpenFlow要求每个实现其接口的交换机配备一个 流表（Flow Table），流表用来记录符合某一规则的数据包的处理方式。

其实我觉得对这个机制的理解可以类似于软负载中心这么一个概念。

在软负载中：

服务调用者通过软负载中心获得服务提供者的地址，软负载中心处于旁路，服务调用者通过软负载找到服务提供者，软负载中心负责调度以及感知各个节点的状态。

OpenFlow中，交换机不仅是相互的通信，包括对数据包本身的处理都通过控制器的来告知。当交换机本地流表中有与数据包匹配的项目时，就不会再走控制器。大概类似上图的软负载结构如下：

流表也类似一个缓存，当不知如何处理一个数据包的时候交换机就会与控制器通信。

交换机和控制器之间的通信是OpenFlow协议，即基于TCP的一种自定义协议（这里注意TCP是第四层协议。。） 不过这里的链路也只是交换机开的一个特殊的口。不是交换口。

总之，通过以上这种架构，就能够通过对控制器的编程达成对下层网络的控制。在这种体系下实现一些链路层协议就比较容易了。于是我最后毕设做了个VLAN功能（通过在控制器上维持一个VLAN关系表，控制交换机之间数据的VLAN加标去标等事情，然后对连接到交换机的主机们透明）

使用SDN也能实现三层交换机的诸多功能。以及常见的spanning tree等协议。这时的交换机只是简单地执行者，而不会去计算各种算法。

目前的SDN在我看来还没怎么普及。我觉得这种体系首先面临着与软负载中心类似的挑战：

1.控制器负载很高的时候可能会存在错判的可能，即错误认为一台交换机已经down了。而实际交换机之间的网络是通畅的。这时候按理说交换机应该主动去检查网络连通情况，但链路不同怎么能在一起。。。

2.高并发下数据的正确性保证

3.单点扩成集群后同步的效率

还有就是作为二层设备依赖四层协议处理或多或少应该会牺牲些性能。

据说google内部已经把SDN用起来了，这玩意的好坏让时间去证明吧。。

大概就说这么多，写这些也是因为毕设做过，还是应该留下点痕迹。

如果你能看到这里真的是不容易。。谢谢关注。。

阅读全文

2014-08-16 17:20:35

先来个酷炫的。。

呵呵，前段时间阿里云搞了个免费试用，正好博客的图片还没做。就正好试用试用，API看起来比较全，常见几个语言的SDK都有。

我估计也就是开了个HTTP服务，随便找个语言研究下就能找到接口，这个不是重点。

OSS用上后图片加载就不会隔着一堵 q i a n g 了

恩。其实我就是想写博客发现没法上传图片才开始做图片功能，然后灵机一动用OSS存了呵呵呵呵呵

阅读全文

2014-08-15 16:57:39

今天使用TDDL5，做一个查询的时候，遇到了使用临时表的问题。

我当时使用了诸如

SELECT xxx 
FROM table 
WHERE xxxxxx
GROUP BY A
ORDER BY B  

的语法，服务器报了一个SQL错误，告诉我不能创建临时表，除非指定。

于是突然想起了梦实多次答疑提到的这个问题。

其实，在分布式的场景下，一个group by的执行会被TDDL5的优化器转换成 order by  在各个分表中下发查询。

这是为什么呢？

这就不得不考虑到这个聚合如何在分布式场景下执行了。

每个分表查询的数据取出后需要做一个group by的话，通常分段有序是最高效的，这个看看复杂度就懂了。。

于是转换成了order by后，再group by，就相当于执行了 order by A , group by A 。 这时结果是对A有序的。

这时如果再要对B有序，就麻烦了。。我们的做法是，建立一个临时表再来order by。呵呵。这是需要消耗资源的。但也是可以做的，TDDL可以通过SQL的Hint来开启这个功能。

所以，一般情况下，group by 和 order by 不要指定一个以上的字段，如果数据量较小，聚合的操作也推荐在本地做，而不是用临时表的方式。

阅读全文

2014-08-01 11:35:19

第一次听到angular的时候觉得是个很高级的东西，然后我已经不做前端很久了，所以大概很久都用不到了吧。没想到这么快就用上了。

听圣司同学科普了下angular，觉得这货最大特点应该就是所谓的双向绑定了。

我们知道页面和数据一直是前端关注的点。而页面和数据之间在通常的情况下难以打通，那么前端对于复杂数据的处理基本束手无策。

于是现在接到一个任务需要对数据进行略复杂处理而又要实时展现而且没有前端支持的时候，自然而然想到了angular。

多次对demo的研究和对扩展UI用途的了解后，大概用的比较熟了。然后确实感觉到这样做的方便之处——前端工作再也不用基于结(keng)构(die)的DOM操作。所以这里也推荐大家去试试，特别好用。

阅读全文

2014-07-05 21:51:51

不知不觉，就要入职了。

半年来愉快的玩耍圆满画上了句号，虽然最后有点无奈和遗憾，各方面感情都还是挺到位了。毕竟世事无法彻底圆满，最后几天竟然见到了时隔多年的儿时玩伴。酒也确实喝了个够，以至于这个月都不想沾酒。与太多人抒发了太多情感。

不由得回想起了去年今日，愣头青来到杭州，啥都不知道，独自冒险，竟然能够存活了三个月。

而如今，不再是一个人，却总是觉得生活会变得残酷，心里有了割舍不下的，行动也受到了阻挠。

在即将入职之际，还是希望自己能够不忘初心。

衷心感谢那些曾经给予我帮助的人，踏实做好手头每件事而别说太多话。

希望能够创造自己的价值吧。

阅读全文