从0开始学架构
李运华
资深技术专家
立即订阅
38968 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

48 | 再谈开源项目:如何选择、使用以及二次开发?

李运华 2018-08-16
我在专栏特别放送第 3 期谈了如何高效地学习开源项目,主要聊了我在学习开源项目的一些看法和步骤。今天我们再聊开源项目,谈谈如何选择、使用以及二次开发
软件开发领域有一个流行的原则:DRY,Don’t repeat yourself。翻译过来更通俗易懂:不要重复造轮子。开源项目的主要目的是共享,其实就是为了让大家不要重复造轮子,尤其是在互联网这样一个快速发展的领域,速度就是生命,引入开源项目可以节省大量的人力和时间,大大加快业务的发展速度,何乐而不为呢?
然而现实往往没有那么美好,开源项目虽然节省了大量的人力和时间,但带来的问题也不少,相信绝大部分技术人员都踩过开源软件的坑,小的影响可能是宕机半小时,大的问题可能是丢失几十万条数据,甚至灾难性的事故是全部数据都丢失。
除此以外,虽然 DRY 原则摆在那里,但实际上开源项目反而是最不遵守 DRY 原则的,重复的轮子好多,你有 MySQL,我有 PostgreSQL;你有 MongoDB,我有 Cassandra;你有 Memcached,我有 Redis;你有 Gson,我有 Jackson;你有 Angular,我有 React……总之放眼望去,其实相似的轮子很多!相似轮子太多,如何选择就成了让人头疼的问题了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(20)

  • 何磊
    如果公司规模小建议可以直接使用云厂商的产品,因为运维方便。但是如果业务大,很多个性化的配置以及有自己的整套监控系统等,不适合用云厂商产品,无法进行系统整合。

    作者回复: 点赞👍

    2018-08-16
    13
  • 文竹
    依据情况做出选择。比如:我们公司有些组件,mysql,redis都是使用阿里云上的。数据平台则是自己搭建的。

    使用云上的mysql,redis省去了很多运维成本和一些复杂性问题,不如高可用,高性能。总的来说成本较低。

    自己搭建数据平台有如下原因:
    1、集团下面有很多子公司,如果每个公司都要自己专门处理大量数据的话,总合计成本很高。
    2、技术更容易沉淀,能更有效地为集团产业链提供服务。

    作者回复: 你们的思路挺好,大数据确实要统一维护

    2018-08-26
    8
  • 问题究竟系边度
    业务初期,云平台本身提供的服务性能已经满足需求了,同时提供可视化运维,极大降低运维和部署成本,同时有熟悉的专家团队帮忙特殊问题。

    业务发展后,在考虑根据业务特性做定制开发

    作者回复: 正解,参考架构设计的合适原则

    2018-08-20
    6
  • William
    个人认为:
    用云产品的好处是,1.方便快捷,既然是产品那肯定经过包装,对很多bug进行了处理,因此上手快和使用方便;2.云产品自带维护功能,专业性比自建强,不用自己投入大量人力到维护的事情上;
    缺点也有两个:1.羊毛出在羊身上,自带维护功能,意味着费用也会贵一些;2.维护交给第三方,意味着依赖第三方,出现影响业务的紧急情况可能出现支撑不到位,响应缓慢,解决问题需要时间长等问题;

    自己用云服务器搭建的话,自己还是得亲力亲为,坑要自己踩,出现问题自己解决,但是也相应的灵活,有些问题可以结合业务情况来回避。

    作者回复: 正确👍👍👍

    2018-08-16
    6
  • caohuan
    先回答华仔的问题,觉得 根据 业务需求 来选择 云平台 还是 开源软件,如果是 常规性的需求 云平台 就可以满足,如果 有特殊一点的需求,可能需要 自己开发新的模块 满足需求,云平台 一般不提供 你一家 公司 需要的技术。
    本篇专栏 所得,1.不要重复造轮子 2.寻找满足自己所需业务的开源软件 3.选择 成熟的开源 ,关注运维能力,然后仔细测试、小心应用,从非功能性慢慢切换到功能性上应用,最后做好应急方案 4.造适合自己所需求的轮子,应用开源软件的绝好模板。
    2018-11-12
    2
  • 呵呵
    DRY,不是说的是不要随意复制、粘贴代码么

    作者回复: 代码层面不要拷贝粘贴,设计层面不要重复发明轮子

    2018-08-18
    2
  • 波波安
    根据团队的开发实力来决定吧。前期团队小,业务量不大,可以购买成熟方案。

    作者回复: 正解

    2018-09-05
    1
  • 小喵喵
    为了存储高可用,比如在 mongdb写一份,然后在MySQL也写一份,具体怎么写呢?是写找到mongdb,然后由mongdb同步到MySQL吗?还是有其他更好的方法?

    作者回复: 1. 代码写两次,简单粗暴,但可能数据不一致
    2. 脚本同步,但可能出现同步延迟导致数据丢失一部分

    2018-08-20
    1
    1
  • Xg huang
    如果在业务的初始期,项目规模不大的时候,可以考虑直接购买云平台提供的开源服务,因为使用方便,运维成本相对更低。

    随着项目规模变大,如果需要对开源服务做更定制化的开发,就可以考虑自己搭建。这样做不仅开发效率高,而且保持以后云平台迁移的灵活性

    作者回复: 正确👍

    2018-08-16
    1
  • Geek_f8dc6b
    讲的挺好,很在理!

    作者回复: 都是实践经验

    2019-10-15
  • godtrue
    课后思考及问题
    目前的云计算厂商很多都提供了和开源项目类似的系统(例如阿里云的云数据库 HBase),你倾向于购买云厂商提供的系统,还是只是将开源系统部署在云服务器上?理由是什么?
    我会倾向于购买云厂商提供的系统
    理由:如果实力够(不差钱,不差人),最好自己弄,既然购买了云服务器,应该有人钱的短板,既然如此何不再多花一下买下对于的服务,应该更加的省心省事,运维应该也更加方便。当然,视公司发展情况而定,后面自己研究或整个都用自己的都行。

    1:本文核心观点
    1-1:不要重复发明轮子,但要找到合适的轮子!

    1-2:如何找到合适的轮子?
    聚焦于是否满足业务,而不需要过于关注开源项目是否优秀
    聚焦是否成熟,尽量选择成熟的开源项目,降低风险
    运维能力是必不可少的一环

    1-3:如何用好轮子?
    深入研究,仔细测试
    小心应用,灰度发布
    做好应急,以防万一

    1-4:如何仿造轮子?
    保持纯洁,加以包装
    发明你要的轮子
    2019-09-04
  • 海罗沃德
    AWS上就没有mongoDB的服务,如果要用mongo只能自己通过EC2手动搭建,而AWS在nosql数据库上一直强推自家的dynamoDB,而dynamoDB虽然在快速查询上很有优势,但是不能做count,findBy这样的操作,而且数据流量很贵,动不动就超过throttle了,就要加钱扩容,使用成本是mongo的数十倍,通常为了节约成本还要把dynamo里所有的id等metadata数据存在另外的数据库里,先从别的库拿出需要查的id,在用id去dynamo精确查询

    作者回复: 感谢😊

    2019-07-29
  • 陈笑非
    非常不错,赞赞的!
    2019-06-19
  • 安静
    这篇文章写的真好
    2019-01-21
  • 成功
    大买,小构
    2018-09-07
  • 王维
    根据适用性的选择,如果云服务器能满足要求,就使用第三方云平台提供的系统。
    2018-08-27
  • 蛤蟆不好找
    相对简单,不复杂的业务或者业务量少的系统可以直接买,但是涉及到内部业务,或者复杂的业务,最好部署在云服务器,一旦出了问题可以快速的响应以及定位问题,解决问题
    2018-08-17
  • feifei
    买云服务厂商提供的系统
    1,云系统提供了比开源的软件更多的能力
    2,可用性更高
    3,更好的扩展

    直接部署有时会出现,机器重启,缓冲没加载,导致线上问题等
    一般建议使用云厂商的服务
    2018-08-17
  • SeeSharp
    我身边很多人有个坏习惯,开源库版本喜欢用最新稳定版–0.1,以为遇到坑可以在网上获得别人的解决方案,真遇到坑的时候自己又没有能力改或者已经被最新稳定版fix了要么手动把这单个bug fix搬过去要么被迫升版本,怎么劝都劝不动

    作者回复: 哈哈,确实如此,其实我建议用最新的稳定版就可以了

    2018-08-16
  • 右左
    讲开源项目部署到云服务,这样更灵活,后期还可以自己封装,写辅助系统等

    作者回复: 看看其他人的回答😄

    2018-08-16
收起评论
20
返回
顶部