Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

重整工具箱-从开源软件到开放服务

378 views

Published on

重整工具箱-从开源软件到开放服务

Published in: Internet
  • Be the first to comment

重整工具箱-从开源软件到开放服务

  1. 1. 重整⼯工具箱:从开源软 件到开放服务 LI Daobing <lidaobing@gmail.com> 七⽜牛云存储 2014-11-06 上海
  2. 2. • 李道兵 <lidaobing@gmail.com> • Debian Developer • 2004 年开始接触 Debian • qterm, ibus, scim 等软件包得维护⼈人员 • 开源爱好者 • 中⽂文维基百科前管理员 • 参与维护 iso-codes, translationproject.org • python-lunardate, capistrano-scm-jenkins 作者 • 我对开源的看法 • 参与⼀一个项⺫⽬目,贡献我的时间是因为认同他的理念,⽽而不是想改造他的 理念 • Github: http://github.com/lidaobing https://speakerdeck.com/lidaobing
  3. 3. ⺫⽬目录 • 引⼦子 • 演化中的 LAMP • 会发⽣生什么?
  4. 4. 个⼈人观点YY,仅供参考
  5. 5. 引⼦子 • A: 你们在⽤用什么版本管理软件? • B: Github • A: Github 不是⼀一个服务么? • B: 软件也可以是服务 • A: Github 是开源的么? • B: 不是 • A: 你为什么不⽤用开源的版本管理软件? • B: Hmm...
  6. 6. 引⼦子 • 在这⾥里我不想回答刚才的“你为什么不⽤用开源的版本 管理软件”这个问题,其实我们不只⽤用了 github, 我们 还⽤用了 travis(持续集成), hipchat(聊天), 腾讯邮箱, 监 控宝,未来还会采⽤用更多 SaaS 服务。 • SaaS 和传统软件的优劣⺴⽹网上已经有了很多 slides, 我 今天不讲这个。 • 我想讲从我的观点来看未来会发⽣生什么,以及作为⼀一 个程序员应当如何应对。
  7. 7. LAMP • 有⼈人说 LAMP 是开源软件运动(FOSS)的最伟⼤大成果 • 最早的含义 (2000 年左右) • Linux • Apache • MySQL • PHP
  8. 8. LAMP • ⼀一个完整的版本 • Linux / *BSD • Apache / Nginx / Lighttpd • MySQL / PostgreSQL / MariaDB / MongoDB / … • PHP / Python / Ruby / Java / Golang / …
  9. 9. LAMP • 来⾃自⾼高可⽤用的需求 • 狭义LAMP • 缓存层: Memcached/Redis • 存储层: NFS, mogilefs,glusterfs, … • sphinx(全⽂文搜索), rabbitmq(消息队列), …
  10. 10. LAMP • 线上的部分: 狭义LAMP, 缓存, 存储, 全⽂文检索, 消息队列 • 开发的部分 • 软件仓库: SVN/Git • bug管理: Trac/Redmine • 持续集成: Jenkins/Hudson • 部署系统: capistrano/puppet/salt/⼿手动
  11. 11. LAMP • 线上的部分: 狭义LAMP, 缓存, 存储, 全⽂文检索, 消息队列 • 开发的部分: 软件仓库,Bug管理,持续集成,部署 • 运维的部分: • 监控:zabbix/cacti • ⽇日志: logstash/syslog-ng/⼿手动 • 数据分析: hadoop/spark/⼿手⼯工 • 安全升级: CVE/USN
  12. 12. LAMP • 线上的部分: 狭义LAMP, 缓存, 存储, 全⽂文检索, 消息 队列 • 开发的部分: 软件仓库,Bug管理,持续集成,部署 • 运维的部分: 监控,⽇日志,数据分析,⽇日常升级 • 前端的部分: 抱歉我不懂前端
  13. 13. 就差⼀一个写代码的了
  14. 14. 会发⽣生什么? 已经有云服务 • 线上的部分: L, A, M, P, 缓存, 存储, 全⽂文检索, 消息队 列 • 开发的部分: 软件仓库,Bug管理,持续集成,部署 • 运维的部分: 监控(*),⽇日志,数据分析,⽇日常升级 • 前端的部分: 抱歉我不懂前端
  15. 15. 开发相关的软件 • 开发相关的软件:bug管理,持续集成,… • 不要想着⼀一个软件通吃所有需求(程序员都很挑⾷食 的,你能做好⼀一个需求就不错了) • 账号打通/服务打通才是关键(github 是不错的选择) • 常⻅见的软件其实做得都不好
  16. 16. 会发⽣生什么? 已经有云服务 / 即将有云服务 • 线上的部分: L, A, M, P, 缓存, 存储, 全⽂文检索, 消息队 列 • 开发的部分: 软件仓库,Bug管理,持续集成,部署 • 运维的部分: 监控,⽇日志,数据分析,⽇日常升级 • 前端的部分: 抱歉我不懂前端
  17. 17. 那么这些云服务会以什 么形式出现?
  18. 18. 不是现在的PaaS • PaaS 没有操作系统 • 没有操作系统意味着你⽆无法分析现有系统的瓶颈 • 同时你定位线上bug的能⼒力也⼤大服务降低 • ⽆无法(很难)开发有状态的服务,只能⽀支持平凡的架 构。 • Docker 有望改造现有的 PaaS
  19. 19. 也不是公有云 • 能解决部分的问题,⽐比如存储,邮件,短信,还有开 发相关的服务 • 性能是该死的瓶颈 • 数据库,消息队列这些对响应,容量的要求都很⾼高。
  20. 20. 我期望的: 机房云 • 机房的卖点不再仅仅是我有多少带宽,我的联通性有 多好 • ⽽而是我这边已经⼊入驻了多少家服务供应商,有多少典 型⽅方案 • 数据库,语⾳音识别,⾳音视频转码,… • 游戏,移动应⽤用,电商,…
  21. 21. 有些 IDC 已经在做了? • 差之毫厘,谬之千⾥里 • 专业的事情交给专业的⼈人去做 • 你的数据库能优化到什么程度? • 你的视频转码能优化到什么程度? • 让外部团队来竞争,还是⾃自⼰己做,哪个更好?
  22. 22. 这事难点在哪⼉儿? • 云服务本⾝身就很难:安全性,稳定性,公平性 • 全国的机房太多,点太多的话管理难度⼤大幅度增加
  23. 23. 开发者如何做? • 信任,同时⼜又不信任 • 信任: 主动拥抱服务 • 不信任: • 对于服务的返回数据,检查完整性,如果数据完整性 有问题,即使申明正常(⽐比如HTTP协议返回200)也 要按异常处理;对于所有的异常要有详细⽇日志;推动 服务提供⽅方提供 reqId,⽅方便双⽅方联调。 • 对于⽆无状态的服务(⽐比如 email, sms), 找两家,定期 测试,⾃自动切换或备⽤用
  24. 24. Thanks for your attention

×