1. 关于API访问频率限制的一个问题

    工作中涉及一些对外开放的无需特殊权限的API,用户会因为某些需求而通过程序来频繁访问这些API,导致系统的负载陡增,可能影响系统其它功能的正常使用。虽然做了一些优化让这种API尽可能地轻量,但仍然不够,因此需要进行访问频率的限制。

    由于这样的API并不多,所以我们并没有在Nginx这样的反向代理接入层中实现频率限制,而是API自己去实现,而且实现方案比较粗糙 - 基于Memcached的缓存自动过期特性。

    方案的PHP示例实现如下所示:

    // 每个IP一分钟10次
    $limit = 10;
    
    $cache = new Memcached();
    $cache->addServer('127.0.0.1', 11211);
    
    $key = __FUNCTION__.$_SERVER['REMOTE_ADDR'];
    $requestNum = $cache->get($key);
    
    if ($requestNum !== FALSE && $requestNum > 10) {
        echo json_encode(array(
            'code' => 403,
            'message' => '请求太频繁,请一分钟后再试',
        ));
        return;
    }
    
    $cache->add …
    Tagged as : Nginx 笔记 工作
  2. 青云 iframe 应用开发

    上周的主要工作是将产品的功能集成到青云。青云提供 iframe 的方式来集成第三方服务,这是一种互利的做法,而且对于青云来说,实现的代价也非常小。

    先上图,看看集成的效果:

    ygc-in-qingcloud


    对于青云来说,一个iframe应用就是一个URL,由应用开发者提供这个URL,当青云用户访问应用所在的页面时,页面先自动向应用服务器的URL发送数据请求,请求会携带认证信息,应用服务端需要先校验请求确实来自青云,并获取请求中的用户信息,最终响应一个HTML页面内容,青云应用页面收到响应数据后将其置于一个iframe标签中,之后青云用户在iframe页面中的操作都是直接与应用服务器交互。

    qingcloud-iframe-interaction

    上图交互流程的第2步中,青云服务器向用户响应的内容最终会生成一个包含以下内容的页面:

    <form method="POST" action="URL" target="appframe">
        <input type="hidden" name="payload" value="...">
        <input type="hidden" name="signature" value="...">
    </form>
    <iframe id="..." name="appframe" width="100 …
    Tagged as : 笔记 工作 总结
  3. 编译安装MemcacheQ

    MemcacheQ是一个MemcacheDB的变种,用来提供简单的消息队列服务。(注:MemcacheDB并不是一个数据缓存解决方案,而是一个为数据持久化设计的分布式的键-值对数据存储系统,采用memcache协议,以BerkeleyDB作为存储后端,主页)。

    MemcacheQ依赖于BerkeleyDB和libevent,所以需先编译安装这两者。

    1. 从Oracle官网上下载某一版本的BerkeleyDB(这里以5.0.32版本为例)

    解压缩: tar -xvf db-5.0.32.tar.gz

    进入db-5.0.32/build_unix目录后执行: 1) ../dist/configure , 2) make , 3) sudo make install

    默认情况下,会把BerkeleyDB安装到/usr/local/BerkeleyDB.5.3目录下。

    2. 从libevent官网下载libevent …

  4. 工作中的技术人

    工作入职半个月,有些事情不太顺利,还没有正式上手工作,也许大公司的节奏便是如此,但我内心是比较急的,希望能尽快地上手做实际的工作,而不是学习和等待。

    这半个月里,主要是熟悉工作环境,学习了解工作相关的技术。虽说学习,但其实大部分相关技术以前都了解或使用过,只是经验还不够。

    第一周,除了常规的入职事宜,搭建了开发测试环境,并阅读理解工作中使用的web框架。对于这个框架,有太多的吐槽点,严格地说算不上是个框架,可能是因为写得比较早。对于框架,我认为最重要的是为多人协作完成一件事情提供实现上的规范,其次是代码复用,减少工作量。但这个框架除了一些供复用的代码,就啥都没有了。

    第二周,学习巩固PHP基础,一直没认真地学习过PHP,只是在实习的时候做了一些开发,稍微了解了下Yii框架和Zend框架,觉得太复杂了点。除此之外,初步了解组内的运维工作,特别是整个系统的架构。

    经过一番思考,基于自己的理解,昨天编写了一个玩具性质的MVC web框架原型minibean,该框架以路由转发和控制器为核心,所有非静态文件请求的处理都以Application类对象为入口,按照一定规则对请求URI经路由转发找到对应的控制器类,控制器对象中调用模型与视图的类对象等。以后随着开发经验的增加以及对其他开源成熟框架的学习,会不断地完善该框架。在编写该框架的过程中,深感自己经验的不足,特别是对于Model层 …

    Tagged as : 工作 感悟
  5. 弄清问题,再求解决

    今天同事问我:是否有什么python库或工具能够将网页内容转换成图片格式的。他在做这方面的事情,还没有好的方法,因为觉得我对python比较熟悉,所以问一下。

    但是我从一开始我就犯错误了。其实我至少应该问一下:为什么要解决这个问题?也就是业务需求是什么?并且稍微一想这个问题其实比较含糊。现在的web页面可以很简单,也可能很复杂。那么这个问题里的“网页”是什么样的网页呢?是任何可能的网页么?目的是需要通过图片来展示网页的哪个部分的信息还是整个网页?这些问题我都没问,也没仔细考虑。

    在没有明确需求的情况下,我就认为是将任何形式的网页完整地转换成图片,但又没弄清如果是这种情况问题的难度有多大。

    在听完问题后,我就想到可能有两种方法:1. 先将网页转换成pdf,然后转换成图片,因为我对于将网页转换成pdf格式的方法有点印象;2.可能存在python实现的工具直接将网页转换成图片格式。你是否发现我的思路有个误区:问题的解决方案需要python代码实现,我假设了需要将这个功能嵌入到一个大的程序中。

    然后我就开始蒙头google找方案。经过一番“艰苦卓绝”的查找,发现:1.确实有如xhtml2pdf等工具能将网页转换成pdf格式,但貌似对于中文的支持不是很好;2.没有好的python库或工具能够直接将网页转换成图片格式,有的方案要收费,有的方案需要调用第三方API,而公司的数据明显是不能让第三方获得的。

    在查找解决方案的过程中,我也逐步意识到上述的那些问题,特别是若假设需要将任何形式的网页转换成图片格式 …

    Tagged as : 笔记 工作

Page 1 / 1