从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开始学架构
登录|注册

41 | 互联网架构模板:“开发层”和“服务层”技术

李运华 2018-07-31
上一期,我介绍了互联网架构模板中的存储层技术。关于这部分内容,我将逐层介绍每个技术点的产生背景、应用场景和关键技术,希望让你可以对整体的技术架构有一个全貌认知。
今天我们来聊聊互联网架构模板的“开发层”和“服务层”技术

开发层技术

1. 开发框架
在专栏第 38、39 期中,我们深入分析了互联网业务发展的一个特点:复杂度越来越高。复杂度增加的典型现象就是系统越来越多,不同的系统由不同的小组开发。如果每个小组用不同的开发框架和技术,则会带来很多问题,典型的问题有:
技术人员之间没有共同的技术语言,交流合作少。
每类技术都需要投入大量的人力和资源并熟练精通。
不同团队之间人员无法快速流动,人力资源不能高效的利用。
所以,互联网公司都会指定一个大的技术方向,然后使用统一的开发框架。例如,Java 相关的开发框架 SSH、SpringMVC、Play,Ruby 的 Ruby on Rails,PHP 的 ThinkPHP,Python 的 Django 等。使用统一的开发框架能够解决上面提到的各种问题,大大提升组织和团队的开发效率。
对于框架的选择,有一个总的原则:优选成熟的框架,避免盲目追逐新技术!
为什么呢?
首先,成熟的框架资料文档齐备,各种坑基本上都有人踩过了,遇到问题很容易通过搜索来解决。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(27)

  • feifei

    1,程序没有用适合的语言开发,程序效率低下,比如现在需要开发内存的缓存系统,但团队开发语言是java,java是一门高级语言,适合做业务系统,用java做内存操作内存会效率低下,而且浪费严重
    2,开发框架和开发语言,都是有场景限制的,尺有所短,寸有所长这个道理在哪里都是一样的,c的优势在底层,java在应用,每一个都有所长所短

    解决方案
    1,将业务服务化,对外提供统一的API,各业务通过API调用完成,这样每一个业务都可以使用不同的开发语言和框架完成,各系统完全解耦。
    2,容器化,使用docker将平台统一化,更好的可维护和扩展

    作者回复: 分析到位👍

    2018-07-31
    21
  • narry
    问题就是可能发生“手里有锤子后,看到什么都是钉子”的情况,在业务规模小的时候采用单一语言单一框架,当规模大了还是应该有一定的灵活性,有一个主力的语言和框架,合适的工作用合适语言和框架,而微服务架构的比较适合混合语言和架构的模式

    作者回复: 赞同👍

    2018-07-31
    13
  • 孙振超
    如同没有包治百病的神药一样,每一个开发框架和语言也只能能解决某些场景,适合某些情况。

    在公司中一方面会选择一个可以适应于大多数场景的主流的开发框架和语言,保证工作效率、人才体系和技术积累;同时也会根据特定场景选择其他的开发框架或语言,而后通过开发client包或采用约定协议的方式将异构的系统链接到一起,共同为业务服务。

    作者回复: 赞同👍

    2018-09-28
    4
  • 文竹
    出现的问题:
    1、违背了合适原则,本来用C++语言最合适,偏偏使用了Java
    2、容易出现思维盲区,有可能有更好的替代品

    解决问题:具体问题具体分析,规范是也是需要不断完善的,不能盲目遵守。

    作者回复: 赞同👍

    2018-08-26
    4
  • 劉阳河
    老师,我记得SOA和微服务的章节说,SOA相当于多合一,将拆出来的各服务用EJB总线连接起来,这也是微服务架构和SOA的区别,那微服务的服务中心和EJB总线有什么区别呢

    作者回复: 你可以这样理解:EJB=所有微服务基础设施的全集

    2018-11-15
    2
  • Tom
    怎么保证消息队列的可靠性呢,万一消息队列集群挂了怎么做到消息不丢失?我想到的方案是发布消息之前先将消息表保存到数据库,消费方通过接口等方式变更消息表状态,服务定期检查消息表状态,将被未经处理的消息重发。帮我看下这样可行吗?谢谢:)

    作者回复: 发之前缓存,可以记录到本地,也可以记录到数据库,但这个方案的复杂度比较高,且建议只有发送失败的时候这样做,但其实还是没有保证完全不丢失,因为也可能发送到消息系统后消息系统挂了

    2018-08-10
    1
  • 性能
    李老师,服务总线系统,就是企业ESB吧?对于大型金融类企业来说,服务总线系统更合适吧?服务名字系统每台机器都要拉取一大堆服务配置信息,配置信息更新也不够及时。请问阿里用的是哪种呢?

    作者回复: 1. SOA架构就是ESB,互联网就是微服务的服务中心。

    2. 服务名字系统确实需要拉取服务配置信息,但对于机器来说,几万条信息完全没有压力,所以不要担心。
    3. 配置更新要及时的话,有几种做法:配置推送,配置定时(例如每秒)校验,zk配置变更通知。用得最多的反而是定时校验,校验做的很轻量级,每次只要校验配置版本号或者配置hash值

    2018-08-09
    1
  • 但莫
    今天介绍的内容是围绕着为服务架构所必须的几个组件,后续是否会详细介绍每个组件的设计原理呢。

    使用统一的语言可能会限制实现功能的想象力和方案的选型和实现,拿着锤子,看什么都是钉子。
    要实现多语言开发可以通信,可以使用规范的协议,而非语言特性。如restfull,自定义协议等。

    作者回复: 每个组件设计原理合起来可以开另外一个专栏了,本篇只是提炼重点内容

    2018-07-31
    1
  • Geek_88604f
    技术上,不存在一个包打天下的框架。在业务发展的过程中总会遇到框架不适合解决的场景,如果死守原有的框架削足适履必然会带来不利的影响:开发效率低、工作量大、系统不稳定等;
            管理上,团队中总会存在对技术有追求的员工,应鼓励这些员工引入新框架,有利于员工的职业发展,有利于团队的稳定,有利于营造较好的技术氛围;
            战略上,框架一旦受限将是灾难性的。特别是大公司必须考虑框架受限时如何生存的问题。最近M国将H公司列入实体名单的事件相信给每个大公司提了个醒,要有备胎。
    2019-10-11
  • Ericens
    李老师,请教个关于协程与线程的疑问。比如,a协程调用socket. read(),此时数据没有准备好,则继续调度b协程。

    把协程换成线程,上面这个过程哪个更加轻量?协程还是线程?
    我理解这个过程涉及的过程如下,都一样。
    1.都有系统调用read(),从用户态切换到了内核态,
    2.都有上下文切换。(不同协程的寄存器,和不同线程的寄存器)
    3. 都要执行任务调度。协程调度或者线程调度。

    那协程到底轻量在哪?

    作者回复: 协程是用户态判断,不会切换到内核态,没有上下文切换

    2019-10-10
  • kfighter
    springCloud,算是服务名字系统吗?

    作者回复: 这个是微服务全家桶,里面什么都有

    2019-10-08
  • Sam.张朝
    语言都有使用的场景,一种语言不能胜任所有的开发场景。
    2019-09-29
  • godtrue
    课后思考及问题
    1:这节不费脑,使用统一的开发框架和开发语言可以让团队开发效率更高,但这样做会带来什么问题?
    大一统是为了沟通交流管理方便,提高工作效率,提升团队凝聚力。
    带来的问题,如下:
    1-1:限制了某些场景使用更加合适工具的选择,这是最核心的,选择大于努力,选择错误越努力越费劲
    1-2:语言和框架都有其存在特点,针对某些场景都有其功能优势,架构三原则,合适第一
    1-3:使用某些场景强行使用不合适的语言或框架,会适得其反,不但效率不高可能会更低下
    1-4:其实就像一国之兵种,海、陆、空在不同的战场有不同的优势
    2019-09-04
  • 康斯坦丁
    1 随着时间积累,切换语言的风险越来越大。
    2 缺乏技术创造力,不同的语言有其不同的适合场景
    2019-08-18
  • 花花大脸猫
    小公司的话肯定使用统一开发框架以及语言,效率最大化而且更容易管理掌控,在当前的业务场景下能够满足要求,但是当业务规模以及复杂度上来的时候,统一的框架以及语言会带来局限性就会非常明显,可选范围非常局限,所以这时候需要考结合务场景的要求,来选择合适自己的框架以及开发语言,往多元化进行考虑。
    2019-04-21
  • Sic Pavis
    使用统一语言和框架,很可能限制技术人员的技术视野。一遇到问题下意识地想在这个框架或语言里我需要怎么解决。实际上可能有更合适的其他方案,对于一些细枝末节可以妥协,但是对于一些核心技术方案,则需要再做商议

    第二就是整个技术团队更换框架的时候可能会因为步骤不一致导致一些团队沟通问题
    2019-04-19
  • 杨陆伟
    服务总线系统相比服务名字系统虽然有诸多优点,但是性能可能会略差,而且服务名字系统的sdk一般放在上层公共镜像中,所以也具备一定的通用性,不知道这样理解是否正确?

    作者回复: 服务总线系统可靠性存在风险,服务名字系统sdk是通用的

    2019-04-14
  • 乘风
    使用统一的开发框架和语言可以降低团队的沟通成本和学习成本,但不能因地制宜,不同的业务采用适合的技术去解决。
    问题:
    1.解决效果无法达到预期,如性能效果,如展示效果,比如java也可以做pc的应用程序,但界面效果和运行效果都无法媲美c,
    解决方法:根据不同的业务场景,参考业界主流和自身的情况采取合适的方式实现(有点像废话),但目前做的业务系统上确实没有照搬主流,更多是依据自身的情况,如成本、人员情况。
    2018-12-17
  • 小狮子辛巴
    弱弱的问一句老师,只能php的能成为架构师吗?

    作者回复: 架构师是分级的,参考特别放送的内容,只会PHP会限制你的选择范围,因此要成为优秀的架构师,只会PHP不太够

    2018-11-21
  • 孙振超
    每一个开发框架和语言都有适合自己的应用场景,
    2018-09-28
收起评论
27
返回
顶部