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