46 | 服务端开发篇:回顾与总结
许式伟
该思维导图由 AI 生成,仅供参考
你好,我是七牛云许式伟。
到今天为止,我们第三章 “服务端开发篇” 就要结束了。今天,让我们对整章的内容做一个回顾与总结。本章我们主要涉及的内容如下。
服务端开发这个分工,出现的历史极短。如果我们从互联网诞生算起也就 40 多年的历史。以进入民用市场为标志,它真正活跃的时段,其实只有 20 多年。
作为架构师,记住这一点非常非常重要。20 多年能够形成的有效经验并不多。这意味着我们不能固步自封,很多惯例是可以被挑战的,并且最终也必然被挑战的。
作为最底层的服务端操作系统,最初从桌面操作系统而来。但桌面操作系统自身在发展,服务端操作系统自身也在发展,两者渐行渐远。
桌面的领域特征是强交互,以事件为输入,GDI 为输出。
所以,桌面技术的迭代,是交互的迭代,是人机交互的革命。在 “13 | 进程间的同步互斥、资源共享与通讯” 一讲中,我们介绍了桌面操作系统中进程间协同方式的变迁。如果我们从业务需求角度看,这个变迁本质上也是交互的变迁(为什么我们这么说?欢迎留言探讨)。
而服务端程序有很强烈的服务特征。它的领域特征是大规模的用户请求,以及 24 小时不间断的服务。这些都不是业务功能上的需要,是客户服务的需要。
所以,服务端技术的迭代,虽然一开始沿用了桌面操作系统的整套体系框架,但它正逐步和桌面操作系统分道而行,转向数据中心操作系统(DCOS)之路。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
服务端开发在互联网领域的重要性日益凸显,本文从历史、技术演进和架构设计等多个角度对服务端开发进行了全面回顾与总结。文章首先指出服务端开发的短暂历史,强调了服务端技术的快速迭代和挑战。随后,重点介绍了负载均衡和存储中间件在服务端开发中的重要性,以及它们对业务架构的影响。此外,文章还提到了服务端程序的特点和服务治理的边界,强调了服务端开发与服务治理的区别和联系。 在内容回顾部分,文章详细介绍了服务端开发所涉及的基础软件、负载均衡和存储中间件的重要性,以及它们对业务服务器的压力均衡和优雅升级的作用。此外,还对存储中间件的种类和服务端主要实现的多租户的 Model 层进行了阐述。最后,文章强调了详细设计的重要性,包括现状与需求、需求满足方式和实现原理等内容。 在参考资料部分,文章列举了一些值得关注的技术,包括Docker & Kubernetes、Go语言、LVS & Nginx、MySQL & MongoDB等,为读者提供了进一步深入学习的方向。 总的来说,本文通过对服务端开发的回顾与总结,为读者提供了全面的技术视角和发展趋势,使读者能够快速了解服务端开发的重要性、技术特点和相关学习方向。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《许式伟的架构课》,新⼈⾸单¥68
《许式伟的架构课》,新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(10)
- 最新
- 精选
- 小名叫大明老师,很感谢您推荐的值得重点关注的技术列表,我深知他们的重要性,可是我有一个疑惑,了解到什么程度呢? 是越深越好哈?还是应用级别,浅层原理级别,深层原理级别?
作者回复: 以串联知识为要,深入的那部分,应该是对你业务最相关或者是你兴趣最相关。
2019-10-0239 - Louis问下许老师,服务端治理是不是就是运维?
作者回复: 服务治理包括运维
2019-10-0337 - Eternal服务端开发这个分工,出现的历史极短。如果我们从互联网诞生算起也就 40 多年的历史。以进入民用市场为标志,它真正活跃的时段,其实只有 20 多年。作为架构师,记住这一点非常非常重要。20 多年能够形成的有效经验并不多。这意味着我们不能固步自封,很多惯例是可以被挑战的,并且最终也必然被挑战的 重复一下老师的话,这给所有有志成为一名架构师的小伙伴一个诗和远方!!!2019-11-232
- Geek_88604f桌面技术的迭代是交互的迭代——为什么这么说?结合老师以前的文章,我说一下个人的理解,桌面技术可以划分为桌面应用和桌面交互两个方面,桌面技术的发现和演进必然是由这两个方面共同驱动的,它俩像人的两条腿一样共同带领桌面技术稳步前进。 先来看桌面应用,如果按照网络发展的时间轴来划分桌面应用,大致可以划分为单机应用、网络应用、移动应用这三个时期。在单机应用时代桌面应用有文本编辑、语音、视频、游戏等;到了网络时代,桌面应用还是以那几个为主(网络支付是新产生的),只不过增加了资源共享的能力(典型的如BT下载,共享的安全也需要考虑);但是到了移动时代,桌面应用出现了爆炸式的增长,从数量上来看各种各样的APP和小程序如雨后春笋(如何快速安装和卸载,即插即用,兼容性,应用的故障隔离等),从质量上看出现了以语音识别和图像识别为代表的智能应用(这些智能应用往往需要移动端的和后台的紧密协作),这些应用的发展必然会导致桌面技术和架构的不断迭代和演进。 再来看桌面交互,交互方式经历了命令行交互、字符界面、图形界面、智能交互(触摸屏+语音为主)这几个阶段。其中字符界面到图形界面是交互技术的第一次飞跃,从架构上目前来看智能交互框架还不能和现有的框架很好的兼容像素可以有独立的属性(每个像素可以有不同的颜色)。从图形界面到智能交互是可能的第二个飞跃,目前来看还主要是语音交互(语音识别、语音助手)并且智能交互框架还不能和现有的框架很好的兼容(语音交互的上下文、语音交互框架的独立性)。如果以人与人之间的交互来类比的话,桌面交互的翻天覆地的变化是越来越自然的提现了交互的本质,后续必将和现有的框架完美融合同时还会出现新的交互方式以丰富交互的多样性,如动作识别、表情识别。这些新型交互技术的出现必将驱动桌面交互技术向着越来越自然、越来越智能的方向前进。2019-10-042
- 随心而至我刚工作一年多,做的服务端开发,刚开始技术繁杂,令人眼花缭乱,学习老师的专栏,暂时就是知道该学习那些知识,什么个次序,至于架构师应该是水到渠成的事情。2019-10-022
- Aaron Cheung不能固步自封 挑战部分惯例 国庆快乐 打卡462019-10-012
- 丁丁历险记how about redis?yy2019-11-031
- ifelse学习打卡2023-09-16归属地:浙江
- 不温暖啊不纯良速错这个概念,指在程序中遇到错误后,能够迅速的抛出错误,让程序员定位的错误,当我们需要对一些特定程序,比如连接数据库程序,对它们做try catch操作,仅仅应该把这一行需要处理异常的代码,用try代码块来包起来,就这样才更易于在维护过程中和调试过程中定位错误。 我遇到在实际开发中有很多 Try catch 操作,其实只是把异常隐藏了起来,并没有做任何处理,而且把无关代码也放进try 块中,只为了定义变量的方便。关于这个问题,事实上我们只应该在不得不做预处理的时候使用try catch ,比如某些组件抛出的异常,而且在处理这类异常的时候,尽量不要再牵扯到其他代码,try块一定要小,一定只包含发生此类异常的代码。2021-05-02
- Run真不错2021-03-03
收起评论