Δια στόματος Tim Cook εκφράζεται η άποψη της Apple αναφορικά με το βαθμό στον οποίο οι χρήστες θα ελέγχουν τα δεδομένα τους.  O Διευθύνων Σύμβουλος της Apple καλεί την αμερικανική Κυβέρνηση να δώσει στους χρήστες τα κατάλληλα εργαλεία προκειμένου να μπορούν να ελέγχουν με απόλυτο τρόπο όλα τα online δεδομένα που συλλέγονται από εκείνους. Σύμφωνα…

Το Vodafone TV υποδέχεται το National Geographic+, την υπηρεσία on demand διανομής περιεχομένου ντοκιμαντέρ, η οποία καλύπτει πάνω από 40 διαφορετικές θεματικές κατηγορίες. Έτσι, οι συνδρομητές του Vodafone TV έχουν πλέον πρόσβαση σε περισσότερα από 700 επιλεγμένα συναρπαστικά ντοκιμαντέρ, παρουσιασμένα σε 40+ θεματικές κατηγορίες με την υπογραφή του National Geographic, με την καλύτερη ποιότητα θέασης.…

Το ποσό των 50 εκατομμυρίων ευρώ καλείται να πληρώσει η Google για παραβιάσεις του Γενικού Κανονισμού Προστασίας Προσωπικών δεδομένων (GDPR).  Σύμφωνα με τις επιταγές του GDPR, ο οποίος έχει ήδη τεθεί σε ισχύ στην Ευρώπη, η Υπηρεσία Προστασίας Προσωπικών Δεδομένων της Γαλλίας επέβαλλε πρόστιμο 50 εκατομμυρίων ευρώ στην Google λόγω του ότι δεν καθιστά σαφές…

Οι ειδικοί της Kaspersky Lab έχουν συμβάλλει στην έρευνα «Good Practices for Security of Internet of Things in the context of Smart Manufacturing», με στόχο την υποστήριξη της ανάγκης για αυστηρά πρότυπα ασφάλειας του IoT. Η έκθεση, που αναπτύχθηκε από τον Ευρωπαϊκό Οργανισμό για την Ασφάλεια Δικτύων και Πληροφοριών (ENISA), στοχεύει στην ενίσχυση της ασφάλειας…

Σύμφωνα με έρευνα της Kaspersky Lab, η συνδεσιμότητα είναι στις μέρες μας ζωτικό κομμάτι του καθήκοντός μας απέναντι στην οικογένεια, τους φίλους και τα αγαπημένα μας πρόσωπα. Η έρευνα δείχνει ότι στις περιπτώσεις που οι άνθρωποι δεν μπορούν να χρησιμοποιήσουν τις συσκευές τους, οι συνηθέστερες ανησυχίες τους είναι ότι η οικογένεια και οι φίλοι τους…

Το Viber λανσάρει διεθνώς τα Polls, το νέο εργαλείο ζωντανών δημοσκοπήσεων, και «φέρνει δημοκρατικές διαδικασίες» σε Group chats (ομαδικές συνομιλίες) και σε Communities (κοινότητες). Με το νέο χαρακτηριστικό εμπλουτίζεται ακόμα περισσότερο η επικοινωνία, καθώς οι χρήστες μπορούν να συμμετέχουν και να εκφράζουν την άποψή τους για διάφορα θέματα με έναν εύκολο και γρήγορο τρόπο. Η…

前面有一篇文章中提到过开源软件，不过主要是在系统运维的角度去讲的，主要分析一些系统级的开源软件(例如bind,memcached)，这里我们讨论的是用于搭建初创网站应用的开源软件(例如phpbb,phparticle)，运行在Linux，MySQL，Apache,PHP,Java等下面。 创业期的网站往往采用比较简单的系统架构，或者是直接使用比较成熟的开源软件。使用开源软件的好处是搭建速度快，基本不需要开发，买个空间域名，下个软件一搭建，用个半天就搞定了，一个崭新的网站就开张了，在前期可以极大程度的节约时间成本和开发成本。 当然使用开源软件搭建应用也存在一些局限性，这是我们要重点研究的，而研究的目的就是如何在开源软件选型时以及接下来的维护过程中尽量避免。 一方面是开源软件一般只有在比较成熟的领域才有，如果是一些创新型的项目很难找到合适的开源软件，这个时候没什么好的解决办法，如果非要用开源的话一般会找一个最相似的改一下。实际上目前开源的项目也比较多了，在sf.net上可以找到各种各样的开源项目。选型的时候尽量应该选取一个程序架构比较简单的，不一定越简单越好，但一定要简单，一目了然，别用什么太高级的特性，互联网应用项目不需要太复杂的框架。原因有两个，一个是框架复杂无非是为了实现更好的可扩展性和更清晰的层次，而我们正在做的互联网应用范围一般会比开源软件设计时所考虑的范围小的多，所以有的应用会显得设计过度，另外追求完美的层次划分导致的太复杂的继承派生关系也会影响到整个系统维护的工作量。建议应用只需要包含三个层就可以了，数据(实体)层，业务逻辑层，表现层。太复杂的设计容易降低开发效率，提高维护成本，在出现性能问题或者突发事件的时候也不容易找到原因。 另外一个问题是开源软件的后期维护和继续开发可能会存在问题，这一点不是绝对的，取决于开源软件的架构是否清晰合理，扩展性好，如果是较小的改动可能一般不会存在什么问题，例如添加一项用户属性或者文章属性，但有些需求可能就不是很容易实现了。例如网站发展到一定阶段后可能会考虑扩展产品线，原来只提供一个论坛加上cms，现在要再加上商城，那用户系统就会有问题，如何解决这个问题已经不仅仅是改一下论坛或者cms就可以解决了，这个时候我们需要上升到更高的层次来考虑问题，是否需要建立针对整个网站的用户认证系统，实现单点登录，用户可以在产品间无缝切换而且保持登录状态。由于网站初始的用户数据可能大部分都存放在论坛里，这个时候我们需要把用户数据独立出来就会碰到麻烦，如何既能把用户数据独立出来又不影响论坛原有系统的继续运行会是件很头痛的事情。经过一段时间的运行，除非是特别好的设计以及比较好的维护，一般都会在论坛里存在各种各样乱七八糟的对用户信息的调用，而且是直接针对数据库的，这样如果要将用户数据移走的话要修改代码的工作量将不容忽视，而另外一个解决办法是复制一份用户数据出来，以新的用户数据库为主，论坛里的用户数据通过同步或异步的机制实现同步。最好的解决办法就是在选型时选一个数据层封装的比较好的，sql代码不要到处飞的软件，然后在维护的时候保持系统原有的优良风格，把所有涉及到数据库的操作都放到数据层或者实体层里，这样无论对数据进行什么扩展，代码修改起来都比较方便，基本不会对上层的代码产生影响。 网站访问速度问题对初创网站来说一般考虑的比较少，买个空间或者托管服务器，搭建好应用后基本上就开始运转了，只有到真正面临极大的速度访问瓶颈后才会真正对这个问题产生重视。实际上在从网站的开始阶段开始，速度问题就会一直存在，并且会随着网站的发展也不断演进。一个网站最基本的要求，就是有比较快的访问速度，没有速度，再好的内容或服务也出不来。所以，访问速度在网站初创的时候就需要考虑，无论是采用开源软件还是自己开发都需要注意，数据层尽量能够正确，高效的使用SQL。SQL包含的语法比较复杂，实现同样一个效果如果考虑到应用层的的不同实现方法，可能有好几种方法，但里面只有一种是最高效的，而通常情况下，高效的SQL一般是那个最简单的SQL。在初期这个问题可能不是特别明显，当访问量大起来以后，这个可能成为最主要的性能瓶颈，各种杂乱无章的SQL会让人看的疯掉。当然前期没注意的话后期也有解决办法，只不过可能不会解决的特别彻底，但还是要吧非常有效的提升性能。看MySQL的SlowQuery Log是一个最为简便的方法，把执行时间超过1秒的查询记录下来，然后分析，把该加的索引加上，该简单的SQL简化。另外也可以通过Showprocesslist查看当前数据库服务器的死锁进程，从而锁定导致问题的SQL语句。另外在数据库配置文件上可以做一些优化，也可以很好的提升性能，这些文章在网站也比较多，这里就不展开。 这些工作都做了以后，下面数据库如果再出现性能问题就需要考虑多台服务器了，一台服务器已经解决不了问题了，我以前的文章中也提到过，这里也不再展开。 其它解决速度问题的办法就不仅仅是在应用里面就可以实现的了，需要从更高的高度去设计系统，考虑到服务器，网络的架构，以及各种系统级应用软件的配合，这里也不再展开。 良好设计并实现的应用+中间件+良好的分布式设计的数据库+良好的系统配置+良好的服务器/网络结构，就可以支撑起一个较大规模的网站了，加上前面的几篇文章，一个小网站发展到大网站的过程基本上就齐了。这个过程会是一个充满艰辛和乐趣的过程，也是一个可以逐渐过渡的过程，主动出击，提前考虑，减少救火可以让这个过程轻松一些。

ICE(Internet Communications Engine)是ZeroC提供的一款高性能的中间件，基于ICE可以实现电信级的解决方案。前面我们提到过在设计网站架构的时候可以使用ICE实现对网站应用的基础对象操作，将基础对象操作和数据库操作封装在这一层，在业务逻辑层以及表现层(java,php,.net,python)进行更丰富的表现与操作，从而实现比较好的架构。基于ICE的数据层可以在未来方便的进行扩展。ICE支持分布式的部署管理，消息中间件，以及网格计算等等。 大道理讲完，言归正传，最近育儿网新增了不少新服务，服务间经常会需要相互调用数据，例如用户中心要取博客系统里的文章啊，论坛里发文后要在积分系统里增加用户积分啊。由于设计时这些服务仅仅基于统一的用户中心，服务间基本是独立的，所以要实现这些调用只能在每个服务上新增为其它服务提供服务的服务-_-!。这个时候有几个可选方案，我们开始选择了xml-rpc，基于http和xml的选程调用，用了一段时间，发现维护成本和访问性能都存在问题。 由于这些中间服务部署的时候是和各自所属的服务部署在一起的，对这些服务做整体的改动就非常困难，要维护起来就比较麻烦。另外由于是什么http和xml作为通信协议，由php实现业务逻辑，性能问题也很明显，而且这些http请求都会在http日志留下足迹，导致我们的日志分析很不精确。这个问题不是太大，但很郁闷，所以我们考虑使用ICE来解决这个问题，至于SOAP什么的就不考虑了，同样效率低下。 实现的过程还是比较顺利，花了三天的时间用c++实现了大部分常用的接口，服务端采用deamon的方式运行，错误日志记在syslog里(/var/log/messages)，客户端PHP，编译进去了IcePHP，调用的方法很简单。现在还存在一些问题，运行的时候会异常退出，还需要一段时间来解决，暂时加了只狗看着，一旦进程里没了就重新启动。 既然要跨平台通讯，就涉及对象描述，ICE使用Slice来对结构，类，方法等进行定义。完了以后服务器端，客户端都按这个来调用和实现。ICE内置的Linux 下后台Deamon实现方案非常简单，只需要从Ice::Service里派生出一个类来，实现run方法，在这个方法里创建adapter对象，并在adapter对象里添加Servants，然后激活这个adapter就可以了，网络层的通信都由ICE接管了。由于是基于tcp/ip的直接通信，比更高层的http通信效率要高很多。 在客户端实现时，我们也碰到了一些小麻烦。一个是内置的$ICE对象用的时候有时需要用global声明，否则可能会出错，另外由于默认情况下Slice中struct对应到php的类型是一个类的实例，而不是一个数组，所以在赋值给页面的时候，smarttemplate以及其它模板系统中可能都会存在问题，可以通过修改模板系统的数据赋值显示代码解决。 我们做了一些性能的测试，同样运行1千次请求，使用xml-rpc实现需要28秒左右，使用ICE实现，只需要3秒多，性能的差距还是很大的，同时在这个过程中没发现有内存泄露的情况，效果还比较理想。 最后感慨一下，ICE是适合人类使用的中间件！

于敦德 2006-6-27 Mixi目前是日本排名第三的网站，全球排名42，主要提供SNS服务：日记，群组，站内消息，评论，相册等等，是日本最大的SNS网站。Mixi从2003年12月份开始开发，由现在它的CTO - Batara Kesuma一个人焊，焊了四个月，在2004年2月份开始上线运行。两个月后就注册了1w用户，日访问量60wPV。在随后的一年里，用户增长到了21w，第二年，增长到了200w。到今年四月份已经增长到370w注册用户，并且还在以每天1.5w人的注册量增长。这些用户中70%是活跃用户（活跃用户：三天内至少登录一次的用户），平均每个用户每周在线时间为将近3个半小时。 下面我们来看它的技术架构。Mixi采用开源软件作为架构的基础：Linux 2.6，Apache 2.0，MySQL，Perl 5.8，memcached，Squid等等。到目前为止已经有100多台MySQL数据库服务器，并且在以每月10多台的速度增长。Mixi的数据库连接方式采用的是每次查询都进行连接，而不是持久连接。数据库大多数是以InnoDB方式运行。Mixi解决扩展问题主要依赖于对数据库的切分。 首先进行垂直切分，按照表的内容将不同的表划分到不同的数据库中。然后是水平切分，根据用户的ID将不同用户的内容再划分的不同的数据库中，这是比较通常的做法，也很管用。划分的关键还是在于应用中的实现，需要将操作封装在在数据层，而尽量不影响业务层。当然完全不改变逻辑层也不可能，这时候最能检验以前的设计是否到位，如果以前设计的不错，那创建连接的时候传个表名，用户ID进去差不多就解决问题了，而以前如果sql代码到处飞，或者数据层封装的不太好的话那就累了。 这样做了以后并不能从根本上解决问题，尤其是对于像mixi这种SNS网站，页面上往往需要引用大量的用户信息，好友信息，图片，文章信息，跨表，跨库操作相当多。这个时候就需要发挥memcached的作用了，用大内存把这些不变的数据全都缓存起来，而当修改时就通知cache过期，这样应用层基本上就可以解决大部分问题了，只会有很小一部分请求穿透应用层，用到数据库。Mixi的经验是平均每个页面的加载时间在0.02秒左右（当然根据页面大小情况不尽相似），可以说明这种做法是行之有效的。Mixi一共在32台机器上有缓存服务器，每个Cache Server 2G内存，这些Cache Server与App Server装在一起。因为Cache Server对CPU消耗不大，而有了Cache Server的支援，App Server对内存要求也不是太高，所以可以和平共处，更有效的利用资源。 图片的处理就显得相对简单的多了。对于mixi而言，图像主要有两部分：一部分是经常要使用到的，像用户头像，群组的头像等等，大概有100多GB，它们被Squid和CDN所缓存，命中率相对比较高；另一部分是用户上传的大量照片，它们的个体访问量相对而言比较小，命中率也比较低，使用Cache不划算，所以对于这些照片的策略是直接在用户上传的时候分发到到图片存储服务器上，在用户访问的时候直接进行访问，当然图片的位置需要在数据库中进行记录，不然找不到放在哪台服务器上就郁闷了。 文章参考：Batara Kesuma在MySQL Users Con 2006上的发言

于敦德 2006-6-27 FeedBurner（以下简称FB，呵呵）我想应该是大家耳熟能详的一个名字，在国内我们有一个同样的服务商，叫做FeedSky。在2004年7月份，FB的流量是300kbps，托管是5600个源，到2005年4月份，流量已经增长到5Mbps，托管了47700个源；到2005年9月份流量增长到20M，托管了109200个源，而到2006年4月份，流量已经到了115Mbps，270000个源，每天点击量一亿次。 FB的服务使用Java实现，使用了Mysql数据库。我们下面来看一下FB在发展的过程中碰到的问题，以及解决的方案。 在2004年8月份，FB的硬件设备包括3台Web服务器，3台应用服务器和两台数据库服务器，使用DNS轮循分布服务负载，将前端请求分布到三台Web服务器上。说实话，如果不考虑稳定性，给5600个源提供服务应该用不了这么多服务器。现在的问题是即使用了这么多服务器他们还是无法避免单点问题，单点问题将至少影响到1/3的用户。FB采用了监控的办法来解决，当监控到有问题出现时及时重启来避免更多用户受到影响。FB采用了Cacti(http://www.cacti.net)和Nagios(http://www.nagios.org)来做监控。 FB碰到的第二个问题是访问统计和管理。可以想象，每当我们在RSS阅读器里点击FB发布的内容，都需要做实时的统计，这个工作量是多么的巨大。大量写操作将导致系统的效率急剧下降，如果是Myisam表的话还会导致表的死锁。FB一方面采用异步写入机制，通过创建执行池来缓冲写操作；只对本日的数据进行实时统计，而以前的数据以统计结果形式存储，进而避免每次查看访问统计时的重复计算。所以每一天第一次访问统计信息时速度可能会慢，这个时候应该是FB在分析整理前一天的数据，而接下来的访问由于只针对当日数据进行分析，数据量小很多，当然也会快很多。FB的Presentation是这样写，但我发现好像我的FB里并没有今天实时的统计，也许是我观察的不够仔细-_-! 现在第三个问题出现了，由于大多数的操作都集中在主数据库上，数据库服务器的读写出现了冲突，前面提到过Myiasm类型的数据库在写入的时候会锁表，这样就导致了读写的冲突。在开始的时候由于读写操作比较少这个问题可能并不明显，但现在已经到了不能忽视的程度。解决方案是平衡读写的负载，以及扩展HibernateDaoSupport，区分只读与读写操作，以实现针对读写操作的不同处理。 现在是第四个问题：数据库全面负载过高。由于使用数据库做为缓存，同时数据库被所有的应用服务器共享，速度越来越慢，而这时数据库大小也到了Myisam的上限-4GB，FB的同学们自己都觉得自己有点懒。解决方案是使用内存做缓存，而非数据库，他们同样使用了我们前面推荐的memcached，同时他们还使用了Ehcache(http://ehcache.sourceforge.net/)，一款基于Java的分布式缓存工具。 第五个问题：流行rss源带来大量重复请求，导致系统待处理请求的堆积。同时我们注意到在RSS源小图标有时候会显示有多少用户订阅了这一RSS源，这同样需要服务器去处理，而目前所有的订阅数都在同一时间进行计算，导致对系统资源的大量占用。解决方案，把计算时间错开，同时在晚间处理堆积下来的请求，但这仍然不够。 问题六：状态统计写入数据库又一次出问题了。越来越多的辅助数据（包括广告统计，文章点击统计，订阅统计）需要写入数据库，导致太多的写操作。解决方案：每天晚上处理完堆积下来的请求后对子表进行截断操作： – FLUSH TABLES; TRUNCATE TABLE ad_stats0; 这样的操作对Master数据库是成功的，但对Slave会失败，正确的截断子表方法是： – ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats1,ad_stats2); – TRUNCATE TABLE ad_stats0; – ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats0,ad_stats1,ad_stats2); 解决方案的另外一部分就是我们最常用的水平分割数据库。把最常用的表分出去，单独做集群，例如广告啊，订阅计算啊， 第七个问题，问题还真多，主数据库服务器的单点问题。虽然采用了Master-Slave模式，但主数据库Master和Slave都只有一台，当Master出问题的时候需要太长的时间进行Myisam的修复，而Slave又无法很快的切换成为Master。FB试了好多办法，最终的解决方案好像也不是非常完美。从他们的实验过程来看，并没有试验Master-Master的结构，我想Live Journal的Master-Master方案对他们来说应该有用，当然要实现Master-Master需要改应用，还有有些麻烦的。 第八个问题，停电!芝加哥地区的供电状况看来不是很好，不过不管好不好，做好备份是最重要的，大家各显神通吧。 这个Presentation好像比较偏重数据库，当然了，谁让这是在Mysql Con上的发言，不过总给人一种不过瘾的感觉。另外一个感觉，FB的NO们一直在救火，没有做系统的分析和设计。 最后FB的运维总监Joe Kottke给了四点建议： 1、 监控网站数据库负载。 2、 “explain”所有的SQL语句。 3、 缓存所有能缓存的东西。 4、 归档好代码。 最后，FB用到的软件都不是最新的，够用就好，包括：Tomcat5.0，Mysql 4.1，Hibernate 2.1，Spring，DBCP。 文章参考了Joe Kottke在MySQL Users