• 2017-09-05

    国内公有云(云主机)服务商选择

    Views: 504 | No Comments

    几年来,已经用过的公有云服务商的产品,将近十家。从最早的 Linode,AWS,到国内的阿里云,青云,腾讯云,UCloud 等,目前来说,国内靠谱只有那一家。具体哪家我不点名,下面分析之后相信你也有自己的答案。

    公有云服务,首先是一个高度沉重的技术活,决不是表面功夫,不是资本牵头整合一下就能做成。

    一方面,厂商必须有相关领域的技术积累,形成深厚的底蕴,最好在虚拟化技术刚出现时就尽早参与。据我所知,国内参与较早的巨头有百度,阿里,华为等,大概在2007年前后就启动并作为战略(但百度的早期的战略更多是应用层引擎,即SAAS,后来此相关尝试没有下文了)。而奇虎360,新浪等,则大致在2010年左右浅尝则止,更多是玩票性质,技术人员弄KPI用的。

    另一方面,厂商必须资金充足愿意大投入,这样才能拥有合格的机房线路等硬件基础。云主机和各种云服务必须运行于真实的物理机器上(宿主机),如果宿主机所处的环境不稳,如供电故障,带宽不足,CPU内存硬盘性能太差等,那么再怎么虚拟化也是扯。

    第三方面,厂商必须自己研发大量的运维和管理系统。这里面对技术的要求也非常高,同时也有很多体力活,另外还要求产品设计简便易用。有些小厂商没有太多的软件研发能力,所以基于开源系统改。有些厂商产品设计能力不足,软件易用性太差,用户管理起来不方便。

    第四方面,客服的专业能力响应速度。云服务是一个技术型服务,并非招几个客服MM摆弄话术就行了,很多时候甚至要求核心底层技术的研发人员和运维和管理系统的研发人员也来充当客服。另外,就是响应速度,别出事了找不着人。

    我曾经用过某小厂商的云主机等云服务,这家厂商对得起其小的称号,其管理系统产品设计得非常易用,非常值得称赞。可借,它资金实力不行,估计是租了比较差的机房,用的服务器硬件也不好,经常网络维护,宿主机硬件故障。这就属于有致命短板的类型。

    我也曾经用过某巨头厂商的云主机,这家厂商资金没问题,但云服务技术底蕴差了点。技术底蕴是非常重要的,通过一些技术细节我评价该厂商为不够真正的专业,外行看不出来,但内行要看细节。这其中的故事细节我有必要说一下,因为你可能不会选择小厂商,但有可能不小心选择了不专业的大牌云服务厂商。

    事情的经过是这样的,我在此厂商处购买了一台云主机,并在附带的系统盘之外,同时购买了一个“云硬盘”作为数据盘(注意,不是系统盘)。后来,为了这个云硬盘是不是所谓的"弹性云盘",和对方的工程师争论了几天。起因是,该云硬盘无法在系统里查到其“软链接”。这个软链接是一个技术名词,类似序列号一样的东西,技术细节可能你不懂,但是,如果没有这个软链接,你就无法正确地将硬盘自动挂载到主机上(该厂商文档极力推荐的方法)。

    这个厂商的工程师先是说 Linux 版本的问题,要我升级 Linux。我举例说,另一个云硬盘在此版本的系统上是正常的。接着对方又说,这个硬盘不是"弹性云盘",我购买时用的姿势不对。没错!对方就是这样不专业。对方说,我不应该在购买主机的同时购买云盘,应该在购买完主机之后再购买。先不说这两种购买姿势没任何区别,我重新发工单问了另一个工程师让它拿着云盘的ID去查,他查完之后明确表示,此硬盘是”弹性云盘“没错。这就非常尴尬了。

    XX云工程师:

    您好,问题明白了,当前我们的弹性磁盘携带serial号便于识别,所以会生成/dev/disk/by-id,其余默认购买的盘不携带serial号,操作系统不识别serial,不生成/dev/disk/by-id 抱歉,让您久等了。

    您好,您这块CBS盘是购买机器的时候一并购买的,这不算弹性云盘,弹性云盘是指的之后单独购买的CBS盘,购买界面如下图。除此之外就是“其余”

    从这个细节可知,该大厂可能没有真正地吃透虚拟化技术的核心,技术总结前后矛盾,自己打自己的脸。

    再次说一下,公有云是一个讲究技术底蕴,技术积累,资本力量,产品设计等多方面因素的技术型产品,选择的时候一定要全面考量。

    Posted by ideawu at 2017-09-05 18:53:12
  • 2017-09-04

    国内某品牌云主机SSH远程后无法在终端显示远程路径的问题

    Views: 271 | No Comments

    如果你用 Mac 自带的 Terminal SSH 远程登录远程主机,那边会在 Terminal 的窗口标题栏显示出类似

    user -- user@host:~
    

    这样的信息。这个信息包含远程主机的用户名,主机名,远程路径等等。非常有用。

    但是,国内某品牌的云主机,却无法显示这些信息。经查,原来该品牌使用的 Linux 系统,/etc/bashrc 文件与其它的不同,我怀疑是该公司的工程师私自改的。他们在文件末尾加上了:

    export HISTSIZE=3000
    export HISTTIMEFORMAT="%F %T "
    export PROMPT_COMMAND="history -a"
    unset HISTCONTROL
    

    正是这一行导致了问题:

    export PROMPT_COMMAND="history -a"
    

    删除即可。

    更新:厂商回复

    您好,这个是我们添加的优化
    目的是在用户在bash上敲了每个命令后,能够及时将命令写入到历史记录文件,防止bash异常退出导致命令没有记录下来,实在不满足您的需求,您可以根据自己的需要考虑取舍。

    又一个"为你好"的坏例子。

    Posted by ideawu at 2017-09-04 16:58:52
  • 2017-06-19

    基于 TCP UDP 协议的实时流媒体的实时性分析

    Views: 1826 | 2 Comments

    直播,电话通话,视频聊天都是实时流媒体的范畴。无论使用 TCP 还是 UDP,都会有延时。有个过时的观点是 UDP 更实时,但我不认为是这样。

    实时流媒体的延时主要有几个因素:发送方缓冲,接收方缓冲,网络延时。缓冲包括网络缓冲,录制缓和冲播放缓冲。假设发送方缓冲是 10ms,接收方缓冲都是 50ms,网络延时是 100ms,那么就有至少 160ms 的播放延时。接收方缓冲比发送方多,是为了解决所谓的 jitter,网络延时不均匀导致的播放断续。

    如果使用 UDP,如果丢包,那么接收方的缓冲就从 50ms 变为 40ms,交互延时变小,随着继续丢包变为 0 时,网络延时不旦不均匀就会发生 jitter 了。这时开始缓冲,一共花 50ms,所以信号中断最多 50ms,也即接收方缓冲。

    如果使用 TCP,丢包会导致 TCP 重传,因为网络 rtt 是 200ms,到 50ms 时,接收方的缓冲已经没有数据了,只能等待网络传输,然后再等 150 ms(也即信号中断 150 ms),突然一次收到 110ms 的数据到接收方缓冲中。为了保证低延时,主动丢弃最早的 60ms 数据。使用 TCP,信号中断时时长是 150 ms,也即网络 rtt 减去接收方缓冲。因为 TCP 最坏情况要重传3次,所以是 3*rtt 减去接收方缓冲。

    Continue reading »

    Posted by ideawu at 2017-06-19 20:31:58 Tags: ,
  • 2017-06-19

    SIP INVITE 会话建立过程

    Views: 1482 | No Comments

    运行于 UDP 之上的 SIP,因为 UDP 是不可靠传输的,所以 SIP 协议本身要自己实现可靠传输。对于如何可靠传输,SIP 的 RFC 文档没有要求实现独立的传输层,而是将可靠传输隐含于交互过程本身。如果像 TCP/IP 协议那样分层,特点是清晰。而将可靠传输隐含于交互,则可控程度更高,当然也更复杂。

    所以,RFC 中创造了一些概念,如 Transaction 等等,对于有经验的程序员来说,这完全没必须,反而造成困扰。对于程序员,用几句简单的过程描述就可以解决。如下。

    Client: 定期重复发送 INVITE 直到收到响应。
    Server:收到 INVITE 后,定期重复发送响应,直到收到 ACK。
    Client:收到响应后回复 ACK,认为会话已经建立。这时如果再次收到响应,回复一个 ACK。
    Server:收到 ACK,认为会话已经建立。这时如果再次收到 INVITE 或者 ACK,丢弃。

    Continue reading »

    Posted by ideawu at 19:05:35 Tags: ,
  • 2017-06-18

    自建一个电话呼叫中心要多少钱?

    Views: 1703 | 5 Comments

    我十分看不惯任何行业的潜规则行为。自建一个电话呼叫中心的报价是多少钱?没有人敢公开报价。我明说吧,自建一个电话呼叫中心,只需要3万元左右,而且还能更省钱。

    这个报价是针对小型企业的,也就是广大人民群众。至于大型企业,它们自己去定制,钱不是问题。

    3万元建一个电话呼叫中心,包括什么?包括硬件设备,软件。软件是硬件设备上免费赠送的,不要钱!有了这个呼叫中心,你可以有语音导航功能(也就是按0转人工客服),还有人工客服排队,电话录音。够用了,中小企业没那么多花哨的需求。

    其它的什么狗屁工单,CRM,根本没人用,没这个需求,不会有人愿意付费的。这年头,开发一个工单系统CRM系统根本就是几块钱的事,再说,现在的公司哪个没有自己的CRM工作流?没有人愿意为这些鸡肋功能付费,所以很多厂商逮着一个人就漫天报价,10万,20万,100万!就想着坑到一个是一个。

    Posted by ideawu at 2017-06-18 00:46:22 Tags: ,
  • 2017-06-16

    SIP tag 和 Call-ID 的区别

    Views: 1400 | No Comments

    SIP 的一次通话,可以通过 From, To, Call-ID 三元组来区分。但是,为什么 From 和 To 不用固定的地址,而要在地址后面加上 tag=随机数 呢?

    tag 的目的是为了解决自己给自己打电话的问题(Hairpinning)。如果你自己给自己打电话,那么你应该有两个 Session,但是,如果 From 和 To 是固定的,你就无法区别这两个 Session 哪个是 caller 哪个是 callee。发送 INVITE 时,caller 会在 From 中带有 tag=随机数,而 callee 发送响应时,在 To 后面补充 tag=随机数,不同的随机数分别表示 caller 和 callee。

    所以,RFC 3261 中说:

    The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship...

    用的是 From tag 和 To tag,而不是用 From 和 To。

    Posted by ideawu at 2017-06-16 19:29:25 Tags: ,
|<<<123456789>>>| 1/120 Pages, 720 Results.