架构实战案例解析
王庆友
前1号店首席架构师
立即订阅
2041 人已学习
课程目录
已更新 15 讲 / 共 22 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 想吃透架构?你得看看真实、接地气的架构案例
免费
概述篇 (1讲)
01 | 架构的本质:如何打造一个有序的系统?
业务架构篇 (9讲)
02 | 业务架构:作为开发,你真的了解业务吗?
03 | 可扩展架构:如何打造一个善变的柔性系统?
04 | 可扩展架构案例(一):电商平台架构是如何演变的?
05 | 可扩展架构案例(二):App服务端架构是如何升级的?
06 | 可扩展架构案例(三):你真的需要一个中台吗?
07 | 可复用架构:如何实现高层次的复用?
08 | 可复用架构案例(一):如何设计一个基础服务?
09 | 可复用架构案例(二):如何对现有系统做微服务改造?
10 | 可复用架构案例(三):中台是如何炼成的?
技术架构篇 (4讲)
11 | 技术架构:作为开发,你真的了解系统吗?
12 | 高可用架构:如何让你的系统不掉链子?
13 | 高可用架构案例(一):如何实现O2O平台日订单500万?
14 | 高可用架构案例(二):如何第一时间知道系统哪里有问题?
架构实战案例解析
登录|注册

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

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

系统的物理模型

对于大部分开发人员来说,我们主要的工作是写业务相关的代码,保证业务逻辑正确、业务数据准确,然后,这些业务代码经过打包部署后,变成实际可运行的应用。但我们写的代码只是系统的冰山一角,为了保证应用能正常运行,我们需要从端到端系统的角度进行分析。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《架构实战案例解析》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(9)

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

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

    2020-03-22
  • 粗线条Jackie
    终于盼到了老师的技术架构篇,很受用。老师布置的作业,除了文中提到的非功能性需求,还有哪些是技术架构目标也是非常重要的,谈下我的理解:
    1. 可监控性。故障不可避免,但如何能第一时间发现问题,快速进行恢复保障业务的连续性是非常重要的。我们建立了平台准实时交易看板,日志报警监控,新功能灰度发布期间运营快速报备通道等组合方案来收集和监控线上故障的发生。
    2.可测试性。除了上线前CI/CD环节的常规Unit Test自动测试通过外,针对修改问题的重现和解决确认,需要在灰度发布期间得到上线验证。此外,像一些常规的无状态会话、扩容后的可承载压力、缓存击穿、单点与服务熔断等场景,也需要定期进行灾备演练。

    最后,我还有两个小话题想与老师再交流一下:
    1. 我注意到一些中小企业,对于架构师的要求更多的在于技术架构层面,而业务架构方面却提及不多。在架构师的升级打怪成长路上,对于企业业务模式的深刻理解,结合企业自身文化、行业特性,甚至团队技能水平,做出切合企业实际的架构设计,感觉也是企业架构师需要面对的挑战。
    2.技术架构的升级与改造,以老师的经验,通常是从业务重要程度低的模块着手(风险低,但也意味着业务 投入低,测试样本量低),还是从业务附加值高的模块下手,新老系统parallel running并逐步过渡呢?

    作者回复: 如果是一个大的技术体系改造,比如引入新的微服务框架,一般从不重要的业务开始,达到验证效果就可以。
    如果是突出点的技术类改造,一般直接做在核心模块上,要能产生大的业务价值。

    你这里补充的系统性功能很好,接下来,专栏会有2篇文章谈系统的可监控性,系统的可监控性就和业务功能的可测试性一样重要。

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

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

    2020-03-18
  • 约书亚
    有一个目标是不能给运维兄弟太难做...监控,预警,线上问题定位,自我恢复这些都要考虑进去。
    还有,我感觉准确/正确性其实也不能算是必然要求了,应该拿出来和其他因素一起衡量,没有哪个系统能保障能100%不出问题,在什么情况下允许出现多严重的问题都可以讨论。
    2020-03-18
  • 夜空中最亮的星(华仔)
    人也很重要
    2020-03-17
  • 孙同学
    除了高可用,高性能,可伸缩,低成本,应该还要易部署,好管理吧
    2020-03-16
  • 孙同学
    https://www.processon.com/view/link/5e51378ce4b0c037b5f9d1e3 学习整理更新
    2020-03-16
  • Jeff.Smile
    要点总结:
    业务架构解决的是系统功能性问题,我们更多的是从人出发,去更好地理解系统;
    而技术架构解决的是系统非功能性问题,我们在识别出业务上的性能、可用性等挑战后,更多的是从软硬件节点的处理能力出发,通过合理的技术选型和搭配,最终实现系统的高可用、高性能和可伸缩等目标。
    思考题:感觉除了高性能、高可用、可扩展和伸缩之外,系统运维比如监控也要考虑进去。
    2020-03-16
  • Mandalorian
    要相对低成本,可以横向的弹性伸缩。
    2020-03-16
收起评论
9
返回
顶部