架构实战案例解析
王庆友
前 1 号店首席架构师
18817 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 23 讲
架构实战案例解析
15
15
1.0x
00:00/00:00
登录|注册

11 | 技术架构:作为开发,你真的了解系统吗?

你好,我是王庆友。从今天开始,我们就进入了技术架构模块,所以,这一讲,我想先跟你聊聊技术架构要解决什么问题。
对于开发人员来说,我们每天都在用技术。但你要知道,我们写的代码,其实只是系统的一小部分,我们了解的技术,也只是系统用到的一小部分。要深入掌握技术架构,我们就需要了解整体的系统。
面对一个复杂的系统,我想你可能经常会有以下困扰:
不清楚系统整体的处理过程,当系统出问题时,不知道如何有针对性地去排查问题。
系统设计时,经常忽视非业务性功能的需求,也不清楚如何实现这些目标,经常是付出惨痛的教训后,才去亡羊补牢。
不知你是否还记得,在第一讲“架构的本质”中,我已经说过,技术架构是从物理层面定义系统,并保障系统的稳定运行。那么今天,我会先分析下系统在物理上由哪些部分组成,让你可以从全局的角度看一个系统;然后再和你一起讨论,技术架构会面临哪些软硬件的挑战,以及它都有哪些目标,让你能够深入地了解技术架构。

系统的物理模型

对于大部分开发人员来说,我们主要的工作是写业务相关的代码,保证业务逻辑正确、业务数据准确,然后,这些业务代码经过打包部署后,变成实际可运行的应用。但我们写的代码只是系统的冰山一角,为了保证应用能正常运行,我们需要从端到端系统的角度进行分析。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了技术架构对于开发人员的重要性以及系统的物理模型和技术架构的挑战。系统的物理模型包括接入系统、应用系统、基础平台和核心组件等部分,构成了一个复杂的端到端系统。技术架构面临硬件处理能力有限和硬件可靠性的挑战,需要考虑垂直扩展和水平扩展来提升处理能力,并应对硬件故障可能带来的影响。文章还介绍了软件在填补硬件缺陷的同时也带来了新问题,以及技术架构的目标包括系统的高可用、高性能、可伸缩和低成本。在处理这些目标时,需要根据业务特点选择最关键的目标予以实现。通过本文的介绍,读者可以更清晰地认识系统的整体结构和技术架构的目标和常见解决手段。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《架构实战案例解析》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(19)

  • 最新
  • 精选
  • 粗线条Jackie
    终于盼到了老师的技术架构篇,很受用。老师布置的作业,除了文中提到的非功能性需求,还有哪些是技术架构目标也是非常重要的,谈下我的理解: 1. 可监控性。故障不可避免,但如何能第一时间发现问题,快速进行恢复保障业务的连续性是非常重要的。我们建立了平台准实时交易看板,日志报警监控,新功能灰度发布期间运营快速报备通道等组合方案来收集和监控线上故障的发生。 2.可测试性。除了上线前CI/CD环节的常规Unit Test自动测试通过外,针对修改问题的重现和解决确认,需要在灰度发布期间得到上线验证。此外,像一些常规的无状态会话、扩容后的可承载压力、缓存击穿、单点与服务熔断等场景,也需要定期进行灾备演练。 最后,我还有两个小话题想与老师再交流一下: 1. 我注意到一些中小企业,对于架构师的要求更多的在于技术架构层面,而业务架构方面却提及不多。在架构师的升级打怪成长路上,对于企业业务模式的深刻理解,结合企业自身文化、行业特性,甚至团队技能水平,做出切合企业实际的架构设计,感觉也是企业架构师需要面对的挑战。 2.技术架构的升级与改造,以老师的经验,通常是从业务重要程度低的模块着手(风险低,但也意味着业务 投入低,测试样本量低),还是从业务附加值高的模块下手,新老系统parallel running并逐步过渡呢?

    作者回复: 如果是一个大的技术体系改造,比如引入新的微服务框架,一般从不重要的业务开始,达到验证效果就可以。 如果是突出点的技术类改造,一般直接做在核心模块上,要能产生大的业务价值。 你这里补充的系统性功能很好,接下来,专栏会有2篇文章谈系统的可监控性,系统的可监控性就和业务功能的可测试性一样重要。

    2020-03-19
    12
  • Geek_kevin
    我觉得技术架构一方面结合当前公司的实际情况,也要结合团队的实际情况,高可用,高性能,可伸缩,低成本,还要考虑团队的技术栈和契合能力。

    作者回复: 是的,要做各种平衡,能接地气。

    2020-03-22
    1
  • 一元硬币
    感觉没有人提到可扩展性,是说可扩展不属于技术架构范畴吗?

    作者回复: 技术的可扩展体现在系统高可用/高性能/低成本上,比如服务无状态保证系统处理能力能够扩展,数据水平拆分提升数据库处理性能

    2021-04-21
  • 粟涛
    怎么缺了应用架构的具体讲述?

    作者回复: 应用架构和业务架构结合一起,放在前面讲了。

    2021-04-02
  • 睡不着的史先生
    web服务器是干嘛的,怎么放在第一层接入了呢?我觉得web服务器就是用来处理http请求解析它的呀

    作者回复: 真正干活的是部署在里面的web应用

    2020-03-18
    2
  • Robin康F
    技术架构除了高可用,高性能,还有安全性,一致性,可维护性
    2020-04-24
    3
  • 张明云
    技术架构除了我在课程中说的几个目标之外,还有哪些目标呢? 1、监控告警:能够监控指标、异常,及时通知提醒; 2、安全性:数据安全、防攻击等安全防护。
    2020-04-01
    1
    3
  • 何知云
    可维护性 1.云服务,CI/CD,减少日常运维成本,专注业务功能开发 2.监控平台、traceId,及时发现系统问题,快速回复 3.自动化测试,快速回归,减少测试成本 安全性 1.外部接口鉴权(加密/签名) 2.应用内鉴权(用户权限管理) 可复用性、可拓展性 1.选型时,使用主流/拓展性强的中间件
    2023-08-14归属地:中国香港
    1
  • 夜空中最亮的星
    人也很重要
    2020-03-17
    1
  • 林铭铭
    还得考虑安全性
    2021-07-23
收起评论
显示
设置
留言
19
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部