从0开始学架构
李运华
资深技术专家
立即订阅
38888 人已学习
课程目录
已完结 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开始学架构
登录|注册

44 | 互联网架构模板:“平台”技术

李运华 2018-08-07
当业务规模比较小、系统复杂度不高时,运维、测试、数据分析、管理等支撑功能主要由各系统或者团队独立完成。随着业务规模越来越大,系统复杂度越来越高,子系统数量越来越多,如果继续采取各自为政的方式来实现这些支撑功能,会发现重复工作非常多。因此我们自然而然就会想到将这些支撑功能做成平台,避免重复造轮子,减少不规范带来的沟通和协作成本。
今天,我就来聊聊互联网架构模板的“平台”技术。由于每个平台本身都是一个庞大的体系,专栏只是介绍一下平台的核心职责和关键设计点,具体细节就不详细展开了。

运维平台

运维平台核心的职责分为四大块:配置、部署、监控、应急,每个职责对应系统生命周期的一个阶段,如下图所示。
配置:主要负责资源的管理。例如,机器管理、IP 地址管理、虚拟机管理等。
部署:主要负责将系统发布到线上。例如,包管理、灰度发布管理、回滚等。
监控:主要负责收集系统上线运行后的相关数据并进行监控,以便及时发现问题。
应急:主要负责系统出故障后的处理。例如,停止程序、下线故障机器、切换 IP 等。
运维平台的核心设计要素是“四化”:标准化、平台化、自动化、可视化。
1. 标准化
需要制定运维标准,规范配置管理、部署流程、监控指标、应急能力等,各系统按照运维标准来实现,避免不同的系统不同的处理方式。标准化是运维平台的基础,没有标准化就没有运维平台
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(14)

  • 天使
    jira+gitlab+jenkins+nexus+bearychat 最简单的DevOps 平台。如果将生产环境完全交给运维团队的话,个人觉得这个应该可以称为开发平台。输入的是需求,输出的是各种工件。

    作者回复: 这个可以算开发平台👍👍👍

    2018-08-09
    11
  • Freedom
    为啥没有产品设计平台,开发平台

    作者回复: 这个问题非常有意思,先说产品平台,实际上是有的,其他例如商务,HR也有平台,但因为专栏聚焦技术,且我对这些平台没有太多理解,所以没有讲。

    再说开发平台,为何我们说数据平台,运维平台等,但不说开发平台呢?我理解是运维平台,数据平台,测试平台,管理平台,产品平台,商务平台等,这些平台都是“管理”平台,运维平台是管理机器和系统,数据平台是管理数据……以此类推,但开发平台如果说管理的话就是代码,但这明显跟我们讲的分层技术栈不是一个概念,所以从整个一个公司的技术架构来讲,一般不会说“开发平台”,但其实狭义的开发平台是存在的,例如maven+git就可以算开发平台,完成代码和包管理

    2018-08-07
    5
  • 小胖狗
    如果运维系统让中间件团队开发
    1.中间件团队需要去理解运维方的需求,他们本身可能并不熟悉运维。
    2.像阿里的中间件团队,看他们的技术博客得知,貌似只专注中间件。
    让运维开发:
    1.运维人员只需将其日常操作平台化即可,能更好的解决运维人员的系统。
    2.当然,这种情况下,运维团队需要形成一定的规模和能力。

    作者回复: 写不了代码的运维不是好的开发😀😀👍👍

    2018-08-07
    5
  • feifei
    中件件团队开发运维或测试平台,这个优势是平台具有很强的通用性,在性能和可靠性上较好,单针对单系统来说,缺少很多针对性的功能,功能上来说就是满足80%,系统的可复用性好!这一般适用于公司开发公司统一的平台
    测试自己开发的平台正好相反,功能100%,但平台就真对单系统,不能复用或复用很小,而且系统的性能和可靠性一般,适用于小业务系统
    2018-08-13
    2
  • 开胃
    中间件团队开发出来的平台一般是通用型的,性能高且易扩展的基础平台,而运维团队和测试团队更加偏于自身的痛点去设计开发
    2018-08-12
    2
  • godtrue
    课后思考及问题
    运维平台或者测试平台,有的公司是由中间件团队负责开发,有的是运维和测试团队自己开发,你觉得两种方式各有什么优缺点,分别适用什么场景呢?
    我们公司的运维平台是中间件团队开发的,性能测试平台是测试团队自己开发的。
    中间件团队的开发
    优点:问题少,规范,统一
    缺点:体验稍差,问题修复慢一些
    适用场景:大厂有中间件团队,需求多,测试或运维研发有困难

    自己的团队开发自己使用的平台
    优点:体验更好,问题修复响应更快
    缺点:代码bug多一些,
    适用场景:运维测试研发能力强,有时间及精力做和维护

    感觉架构实践环节讲的内容大而广,比较靠上层,增长见闻,辅助写PPT可以😄,具体到要做一个东西找最佳实践是找不到的!,老师为啥这么安排?

    作者回复: 给架构师参考用的,尤其是当你需要规划整个公司的技术架构的时候,知道一个全貌和基本的范围更重要

    2019-09-04
    1
    1
  • 孙振超
    最近几期的内容,每一个小主题都可以独立成一个专栏来讲了,在这里只能简要做个介绍。

    对于课后作业,中间件团队来做的优点:平台的性能、可用性、扩展性、伸缩性等非功能性属性会好不少;缺点是在功能性需求上,易用性和需求的响应速度会差些。

    运维或者测试团队自己开发的话优点是:功能完善性好,交互界面符合一线同学的使用习惯。实际上,虽然有些公司也有测试开发工程师和运维开发工程师,但真正的开发水平和开发工程师还是有一些差距,因而缺点可能是开发效率差些,使用的技术也会老些,系统的性能和稳定性差。

    作者回复: 篇幅只能告诉大家一个公司的总体技术架构,知道总体技术架构后,你再按照架构设计的方法论来实现各个系统就可以了😀

    2018-10-03
    1
  • 文竹
    运维和测试平台由中间件团队开发:
    优点:平台架构有保障,代码质量高,开发效率高
    缺点:前期业务沟通成本大
    适用场景:运维和测试开发能力弱。

    运维和测试平台的由运维和测试人员开发:
    优点:前期沟通成本低
    缺点:技术能力弱,开发效率低
    场景:运维和测试开发能力强

    作者回复: 逻辑很清晰👍

    2018-08-26
    1
  • 蛤蟆不好找
    关注点不同,所能设计的产品也会有重点跟非重点的区别,中间件可能更关注的是功能的实现,重点在于技术,
    运维团队可能关注的是平台的运行稳定以及硬件方面的性能
    测试团队在于平台本身功能点的覆盖情况,
    所以由专门的团队来处理,让后其他的队伍提需求

    作者回复: 优势互补,但只有大公司才有能力成立独立的团队来负责各种管理平台的开发

    2018-08-13
    1
  • 旭东
    平台这种需要领导层认可和推动,否则只能在作坊的沼泽里苦苦挣扎。靠开发工程师个人和运维工程师来推动,很是痛苦。

    作者回复: 非常正确,需要一个好的CTO,不然很难落地

    2018-08-09
    1
  • 空档滑行

    1.开发人员关注的技术点不一样,中间件开发人员关心更多的是性能并发这些,对运维整体业务可能了解欠缺一些。运维和测试更偏向业务一点,对中间件关键的功能点可能不会理解很深
    2.运维的kpi是降低成本,提高效率,是能够从数字体现出来的。合理的利用平台和中间件其实是很好的降成本的方式,比如消息队列消息包多大最合适,topic应该怎么划分最合理。硬币总有正反面,两个结合起来可能是最能发挥价值的

    作者回复: 小公司结合可以优势互补,大公司一般有专门的运维开发,测试开发

    2018-08-07
    1
  • jh.mai
    数据平台,初创公司,针对业务数据的一些报表统计,是动态查询好,还是抓取业务数据统一存储!例如:数据库是mysql 业务表有多个,要实现报表统计,需要关联多张表,这时候会存在性能问题,如果是独立报表统计的表,然后抓取数据存储统计,这时候就会发生数据一致性问题。老师有什么好的建议吗?

    作者回复: 抓取业务数据统一存储好一些,因为数据一致性不影响报表整体准确性,几条或者几十条数据不一致没关系,如果大规模不一致那就要重跑报表

    2018-08-30
  • Neal
    由运维,测试团队自己开发,在重复工作达到无法忍受的时候,他们自己会提出构建平台的意向,就像每天手动导入导出数据,后来改成用插件和定时任务自动执行,再到建立自己的平台来执行任务,监控,平台已经自然演进出来了,而中间件的人是感受不到这些痛点的。

    作者回复: 这样做效率比较低😊

    2018-08-09
  • hello
    运维和测试的技术能力没有中间件强,开发效率低。但是中间件团队对运维和测试的痛点需要沟通交流才能理解。如果运维和测试技术OK或者中间件团队对痛点理解OK谁做都一样,就看谁时间多。

    作者回复: 很难做到痛点理解一样,我们有运维开发的运维平台,也有研发开发的运维平台,前者架构设计不行或者没有架构设计,很难扩展,系统不稳定;后者很操作难用😀

    2018-08-07
收起评论
14
返回
顶部