从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)
152573 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 66 讲
结束语 (1讲)
结课测试 (1讲)
从 0 开始学架构
15
15
1.0x
00:00/00:00
登录|注册

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

增加新的消息消费者方便扩展
解耦消息生产和消费
由总线系统完成调用
通过请求方发起请求
解析Service名称为host、port和接口名称
实现高性能、高可用、消息时序性和事务性
简化系统间交互和管理
实现跨系统异步通知
服务总线系统
服务名字系统
快速搭建新环境和恢复业务
实现程序化的规则检查
提高操作效率和协作效率
集中管理系统配置
改变运维方式和设计模式
Docker的容器技术
根据开发语言选择服务器
选择流行的开源服务器
选择成熟的框架
统一的开发框架
如何解决统一开发框架和开发语言带来的问题?
使用统一的开发框架和开发语言可以提高团队开发效率,但可能会带来什么问题?
消息队列
服务中心
配置中心
容器
Web服务器
开发框架
思考题
服务层技术
开发层技术
互联网架构模板的“开发层”和“服务层”技术

该思维导图由 AI 生成,仅供参考

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

开发层技术

1. 开发框架
在专栏第 38、39 期中,我们深入分析了互联网业务发展的一个特点:复杂度越来越高。复杂度增加的典型现象就是系统越来越多,不同的系统由不同的小组开发。如果每个小组用不同的开发框架和技术,则会带来很多问题,典型的问题有:
技术人员之间没有共同的技术语言,交流合作少。
每类技术都需要投入大量的人力和资源并熟练精通。
不同团队之间人员无法快速流动,人力资源不能高效的利用。
所以,互联网公司都会指定一个大的技术方向,然后使用统一的开发框架。例如,Java 相关的开发框架 SSH、SpringMVC、Play,Ruby 的 Ruby on Rails,PHP 的 ThinkPHP,Python 的 Django 等。使用统一的开发框架能够解决上面提到的各种问题,大大提升组织和团队的开发效率。
对于框架的选择,有一个总的原则:优选成熟的框架,避免盲目追逐新技术!
为什么呢?
首先,成熟的框架资料文档齐备,各种坑基本上都有人踩过了,遇到问题很容易通过搜索来解决。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

互联网架构模板的“开发层”和“服务层”技术涉及开发框架、Web服务器和容器等关键技术。统一的开发框架提高团队协作效率和降低技术成本,同时减少技术风险,提高稳定性和可维护性。选择适合自身业务特点的Web服务器至关重要,而容器技术的兴起为运维方式和设计模式带来了革命性的变化。Docker等容器技术的快速启动和资源占用少的特点,将推动自动化运维和微服务设计模式的发展。配置中心、服务中心和消息队列等服务层技术则致力于降低系统间相互关联的复杂度,提高操作效率和协作效率。这些技术的应用将对互联网技术发展产生深远影响,值得关注和探索。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(36)

  • 最新
  • 精选
  • feifei
    1,程序没有用适合的语言开发,程序效率低下,比如现在需要开发内存的缓存系统,但团队开发语言是java,java是一门高级语言,适合做业务系统,用java做内存操作内存会效率低下,而且浪费严重 2,开发框架和开发语言,都是有场景限制的,尺有所短,寸有所长这个道理在哪里都是一样的,c的优势在底层,java在应用,每一个都有所长所短 解决方案 1,将业务服务化,对外提供统一的API,各业务通过API调用完成,这样每一个业务都可以使用不同的开发语言和框架完成,各系统完全解耦。 2,容器化,使用docker将平台统一化,更好的可维护和扩展

    作者回复: 分析到位👍

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

    作者回复: 赞同👍

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

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

    2018-11-15
    2
    16
  • 孙振超
    如同没有包治百病的神药一样,每一个开发框架和语言也只能能解决某些场景,适合某些情况。 在公司中一方面会选择一个可以适应于大多数场景的主流的开发框架和语言,保证工作效率、人才体系和技术积累;同时也会根据特定场景选择其他的开发框架或语言,而后通过开发client包或采用约定协议的方式将异构的系统链接到一起,共同为业务服务。

    作者回复: 赞同👍

    2018-09-28
    15
  • 文竹
    出现的问题: 1、违背了合适原则,本来用C++语言最合适,偏偏使用了Java 2、容易出现思维盲区,有可能有更好的替代品 解决问题:具体问题具体分析,规范是也是需要不断完善的,不能盲目遵守。

    作者回复: 赞同👍

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

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

    2018-08-09
    4
  • cc
    语言有不同的长短板,使用的时候应该扬长避短。语言的选择要考虑到业务场景。不能一刀切

    作者回复: 不能一刀切,但也不要百花齐放😄

    2018-08-02
    2
    3
  • jh.mai
    如果是业务发展初期,设计是一个服务A,服务A下会把各个子模块按包分出来,以便后面的拆分,现在出现另外系统B同样出现A服务的子模块功能,是否可以把A子模块抽取出来当作独立服务呢?

    作者回复: 可以做了,择日不如撞日😄

    2018-08-15
    2
  • wuhulala
    虽然统一的开发框架整体来说开发效率高,但是遇到一些更好的解决方案的时候却只能干瞪眼或者使用当前技术栈实现一遍。整体来说规范性更好,所有的技术问题由技术好一点的来解决,业务开发人员无需关注这么多东西。

    作者回复: 有时候我们需要锤子,但有时候可能电锯更好😄

    2018-07-31
    2
  • WESTWALL
    可以这么理解吗老师? Service Name System:注册中心 + load balance。 Service Bus System:API网关。

    作者回复: 有点类似,但是API网关更多的是负责内外通信,也就是通常说的南北流量,微服务内部通信是东西流量,目前APISIX、istio可以算是Service Bus System。

    2022-01-11
    1
收起评论
显示
设置
留言
36
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部