山东企业网站建设公司,编程软件做网站的,网站建设周期与进度安排,深圳汇网网站建设软件平台架构设计与技术管理之道笔记
认知
领导软件平台各方面的工作#xff0c;对技术底蕴、思维模式、决策能力、工作风格、文化铸造等方面都有极高的要求#xff0c;可以称之为“领域智慧”。认知盲区的代价是巨大的#xff0c;“不知”比“不会”的后果更严重#xf…软件平台架构设计与技术管理之道笔记
认知
领导软件平台各方面的工作对技术底蕴、思维模式、决策能力、工作风格、文化铸造等方面都有极高的要求可以称之为“领域智慧”。认知盲区的代价是巨大的“不知”比“不会”的后果更严重可能导致方向性的错误。
庞大的科技队伍可谓千人千面管理工作中出现举棋不定、迷茫不清时唯有以扎实的认知作为心理的定海神针切不可做无根之水。
在繁冗、枯燥的IT技术工作中埋头干活不能忘记抬头看路主动发现更多的“艺术”细胞增加更多的抽象领悟终会拨云见日。
在工作陷入僵局时回到认知上去审视自我助力破茧而出。
一般而言技术总监职责重在团队建设与管理并对任务完成情况负责架构师则主要在工程和技能领域发挥作用CTO更具统领价值除了更多的管理层事务和外联类工作外还应建立行业影响力、取胜于格局。
硬实力是必需的基础而软技能则决定着技术负责人的最终画像驾驭平台更需要“软实力”加持。
如果能成为开源社区或论坛的活跃者或者是行业规范制定的参与者以此来提升自己在相关领域的影响力则更是加分项。
平台的市场竞争力很大程度上取决于前端的能力用户体验和外部评测直接反映了平台大前端中异步通信、懒加载、压缩、渲染等能力的强弱产品迭代发布的速度直接取决于前端组件化、模块封装复用的架构力和打包部署能力对行业新技术、新生态的跟进则依靠前端团队技术栈和语言的学习与运用能力。
前端领域还是安全问题、兼容性问题的重灾区。
分布式开发框架解决了单体应用的扩展和演进问题带来的弊端是逻辑角度的系统越来越多跨进程系统服务之间的交互越来越多。
云技术的广泛应用服务网格化、开发运维一体化需要掌握和使用云原生能力。
行业技术发展加速了分工细化后者反过来进一步催生技术再发展如此循环上升技术人员必须克服“被其绑架”的困境。
平台技术负责人已经不可能在各个细分技术领域都是专业上的通才无法将主要精力放在技术深度方面。面临着技术团队庞大化、技能差异化技术负责人工作价值和竞争力的体现必须聚焦于“平台技术能力视角”的整体蓝图作为各条产品线开发团队的总架构师、布道师进行全局分域规划、应用系统及服务的颗粒度设计、能力支撑和公共抽象、平台级的组件建设并编排各条产品线间的服务治理、系统间关系、技术复用清晰知道目前进行到哪个阶段筹划要具备什么能力价值是什么以及对问题的合理性技术决策。
鱼与熊掌不可兼得技术部门内部的工作决策尤其是技术主张、架构设计类经常出现没有正确答案、各个团队各执一词的场面就其本身而言确实是客观的例如引用新技术的风险与机遇、微服务拆分的颗粒度、几种开发框架的选择、系统间关系设计及通信协议的选择、对业务数据迁移的风险估计等或者是开发周期短与测试把关要求严之间、质量与交付速度之间、快速解析数据与使用高强度加密算法确保安全之间……无处不在的矛盾体。技术决策的选择不会出现简单的答案各类设计、各种主张都有各自的道理需要技术负责人承担决策责任。 没有完美答案
决策并不是给出完美的答案决策的核心是在有限的时间内尽量充分地沟通合理进行“取舍”其根本是门“折中”的艺术以达到一个平衡的目标多数情况下你并非是以某一个选择作为结果而是多个观点之间的平衡点。
独断专行的决策方式是极左过于民主协商的决策方式为极右两者都有缺陷。
最佳决策应该是在创意择优中按照观点的可信度高低来得出圈定参与决策的人员每人提出自己的观点对于能力强、责任大的人员还应该在过程中努力解决彼此分歧不同能力者观点的权重不同进行可信度加权产生决策参考结果。
决策者没有必要凡事都做出判断但是必须能够适时终止辩论知道如何超越分歧推动就下一步措施形成共识。有时延时决策如放到下次会议上决定是很好的缓释方式。
用心记录决策理由
对于架构设计工作用心记录的决策理由其本身就是一套架构演变文档无论如何这类材料都物超所值。
掌握和使用行业的成例方式作为参考在很大程度上可以帮助我们尽快选定合适的“方法论、表达模式和工具支持”。
“架构视图”一词确系经典但更给人以“从剖面、窗口看到的内容”之感侧重结果的表达含义略显匮乏。如典型的41架构视图逻辑视图、过程视图、物理视图、开发视图、场景视图
“架构主题”更具有对特征的识别、分析以及主旨探索之意。形象化看一个视图是整个平台的横切面。而前端技术架构、大数据架构、统一身份认证架构等是平台纵向的组成部分是一个个领域并非某个视角的全平台横切面。严格说架构设计的对象并非几个经典视图而是包含了一系列的领域对象。既有横切视图也有纵分领域的情况下。
可以借助一些有助于架构决策的方法论工具如架构权衡分析法、成本收益分析法、ADMEMS方法等。
架构的发展历程
第一代是单体(Monoliths)架构 特点水平分层 优点容易上手、部署和测试 缺点耦合性高、技术选型单一、开发效率低下
第二代是面向服务架构(SOA)
特点垂直分层系统之间通过Service API和中心化管理的企业服务总线(ESB)进行交互优点服务化整合和治理缺点每个服务从本质上还是单体服务对ESB严重依赖
第三代是微服务(MicroService)架构 特点水平分层与垂直分层结合将单应用程序作为一套小型服务分布式技术 优点 有服务注册、熔断、容错、自检测、自动发布等能力可快速迭代及持续交付。微服务架构与分布式开发框架相辅相成体现了小团队自治和快速迭代产品发展。 微服务实际上是面向服务架构的一个更好的替代即去中心化的分布式服务架构(DSA)将服务寻址和服务调用完全分开不再依赖于ESB。
第四代是云原生(Cloud Native)架构 特点基于微服务思想以容器为载体提供一种产品研发运营的全新模式。 优点 在开发和运维方面包括基于云的能力资源动态管理Docker容器技术Service Mesh服务网格Serverless无服务器架构API服务化轻量服务无状态化Restful风格化自助管理资源持续集成(CI)持续交付(CD)DevOps开发运维一体化、自动化。
欲言架构必言模式
在内容表述上不论是偏技术形态还是偏思维理念本质是能够用于特定问题的可复用解决方案这就是模式。模式无处不在好的设计方法实际就是模式没有实际边界。
软件架构的基因具有天生的“模糊性”
到底什么是软件架构核心是模式与工具还是理念和思想模式是风格吗微服务到底是架构模式还是架构风格架构模式与设计模式在实际工作任务中它们真地有界限吗
上面这些问题不同专家会有不同的答案。
四代架构的发展历程体现的是核心理念、风格和模式在几十年间的实践并非是银弹技术。和前三代具象的描述方式不同第四代架构的定义已经模糊化是广义的能力包更多的是对应云技术的广泛应用。
但是当前四代架构代次的定义方式未来无法覆盖全部主流。算法开发人员的职业规划估计没能从云原生架构中获益Hadoop大数据开发者对微服务架构也不甚关心。
未来可能没有任何一个词能独自站出来承担起对第五代架构的缩写定义取而代之的是各个领域的分支发展。
不论有无第五代架构其实际意义已然消散。而且不应认为后代比前代好好坏之说过于绝对只能说后代是面向行业发展的新产物软件本身不是目的只有是否适合目标之分如果要做一个很简单的小Demo仍然可以用单体理念找一个最原始的技术栈来实现。
不断涌现的架构代次之说是为表达发展趋势下的主流潮流以及新理念、新技术落地的模式方法。
不应认为架构是“银弹”不应该将过多精力置于考量架构模式的话题上。要明白的是大量的设计方法更广泛存在于程序语言中编写整洁的代码和使用自动化测试对于系统的成败更为重要这仍是现代化软件研发工作的核心。
无为而治
老子《道德经》中所讲治国水平的四个层次
最低层次凭“管理者智力、智谋”
其次是使用“规章制度、条文规范”进行正规化的管理与约束
再高的档次是“包容、仁爱”的美德级别
而四层级的最高档次是“无为而治”。
无为而治需要更多地站在一边观察不要急于发挥自己的权威也不需无处不在的“积极努力”技术负责人缺少的可能是倾听。
学会放手是管理精髓的真正领悟技术负责人应该注意团队是否按照设计和工作计划实现系统但是没有必要站在背后监视大家。
下放工作权限给予团队成员足够的自主和自治让他们发挥自己的创意和能力或许才是技术负责人的最大价值。
架构设计思维原则与模式 架构设计思维原则与模式 以人为本 设计工作的本质是人与人的交往。理解相关方要求驱动下属团队认知。尊重所有干系人换位思考。 延时决策 模棱两可的工程是危险的不到条件成熟的那一刻不要着急做出最终的设计决策。 有些甚至可以放到工作范畴之外留给后来的设计人员去决定。记住这绝不是逃避责任。 借鉴复用 完全可以在别人的基础上开始自己的设计或者使用别人已经搭建好的框架来解决问题。设计架构时必须花更多的时间研究已有的设计减少自己创造避免低效的产出方式。因此广泛阅读、认真学习过大量设计模式的人只要没有模式病就会显得能力更强。 化虚为实 让受众通过感性的认识可以理解和消化如果无法让他人接受想法再好的设计理念和创意也无法产生价值。 理解 研究利益相关方关心的业务目标理解重要的业务需求内容更要了解非功能需求包括开发团队的资源、风格甚至是办公室政治均要做到悉数掌握。 探索 对概念进行定义时的科学性和严谨性架构设计探索是指形成一系列设计概念确定解决问题的工程方法包括研究大量的模式、技术和开发方法。 展示 展示不仅体现四原则中化虚为实所强调的让他人理解和接受你的设计想法并且供架构评估和校验所用。展示想法实际就是架构工作的输出推进协商、制订计划。因此需要注重如何提升架构成果的表现力、表达力。 评估 分享架构的唯一方式就是把它具体呈现出来。很容易理解评估对验证架构设计适用性的作用用于判断是否满足各个干系方的需求。
擅长技术和善于向上管理是两种不同的能力类型技术负责人需要两者兼顾就价值和资源来讲一万行代码也比不上一次领导认可
架构
分界思维
针对大型软件平台的业务需求进行技术功能设计应该参考或者遵循DDD方法作为最佳实践指导。运用限界上下文设计模式识别出所有的上下文即基于业务的问题空间根据核心域、支撑域、通用域几种类型对上下文归类对应形成各个分类的领域模型通过上下文映射(Context Mapping)技术来设计各域之间的关系。
限界上下文的精妙之处在于微服务本质上基本等同于DDD中的限界上下文可以以此来设定微服务颗粒度。分界思维不仅适合新平台、新系统的建设尤其适用于对“大泥鳅”遗留系统的整体重构类任务。
架构模式和设计模式
模式为软件架构师提供了最具价值的工具可以理解为模式按照级别分层可分为架构模式和设计模式前者相对高阶旨在提供系统架构的整体骨架后者颗粒度更细用于解决常见问题如某一系统的组件或者某业务中关键技术级别的组织、通信等。
模式是技术前辈们将设计方法进行抽象提炼总结而成的模板和工具便于后人复用从而帮助我们简洁有效地进行技术设计工作这才是正确的用法必须保持对一切技术任务的洞察力以提供切实有效的、服务于业务的方案进行适度设计获取平衡之道。
在平台建设中首先进行最小化实现即早进行部署确立架构。实现“立起架构”第一时间打通开发、测试、部署、维护的路径第一时间打通从前端工程脚手架到前后端通信到后端访问缓存、数据库和使用管道……第一时间验证各服务节点的服务注册与发现、通信机制有效性甚至是负载均衡的可用性。
保持架构一直处于可用状态中进行递增部署利于建立整体朝着正确方向前进的信心一系列串行工作因此变得更具弹性。并非所有产品都要等到十全十美才能发布递增式部署意味着在可以运行的架构基础上增量式、有选择地进行培育迭代式验证。
打通数据模型
数据模型是什么本质上包括对实体、关系和属性的定义以及所使用的范式。不同的范式在数据冗余与数据完整性上给出不同的原则和约束。
目前数据库的发展历程可以分为三个阶段 第一阶段2000年后的10余年大型商业数据库的天下 如 Oracle、IBM DB2、Teradata 第二阶段约2006年之后MySQL 等开源数据库 开源属性催生了集群化部署以及分库分表、读写分离技术的广泛应用实现了投入成本与性能之间的真正平衡 第三阶段从2012年至今以大数据产业驱动和分布式计算发展带来的Hadoop生态圈 包括NoSQL、HDFS存储、非结构化数据库如HBase列式数据库以及数据仓库(Hive)等
前两个阶段最核心的进步在于互联网思维和开源技术带来的数据库软件技术的飞跃但是“数据存在的形态和主要的应用模式”这些最核心的要素并没有变主流都是SQL标准和范式下二维表的结构化存储和输出形态。
数据库领域的技术一直在变革但“内容为王”的属性和理念一直没变打造坚实的数据库堡垒的系统建设思想20年来从未发生变化。
用户界面和应用逻辑会变化业务会发展人员会变动但是数据会永远保留下来不论二维结构化、还是列式非结构化数据都改变不了数据的不可变特性。鉴于数据的这些特点创建牢固的数据模型要从第一天开始。
内容为王的另一层含义是数据库在企业安全角度被赋予最高使命数据是系统中最高安全级别的是企业中最值钱的资产。
应用可以再造没有数据则一无所有平台运维工作应在数据库和核心数据上多下功夫。加密和脱敏、冷热备份是平台的基础必备能力同时定期攻防和切换演练、灾备中心建设、各类资质和评级此类重要的运维工作都应该以数据为首选主题。
掌握运行水位线及定期演练
进行平台水位线管理主动掌握系统的运行压力线知己知彼则百战不殆。一般有三类方法进行运行水位线评估
一是TPS的估算法
二是操作系统资源使用率估算法
三是历史值估算法。
定期演练的工作机制可以用于揭露“水面下的冰山”。主备中心级别的切换演练、物理机的宕机演练、核心数据库的停服演练、网络DNS解析服务商更换等都是良好的演练主题切记“实际演练发现问题”比“一万次会议强调自查”更管用这种良性的、自揭伤疤的方式是应对技术人员“自查自提升”惰性的最佳手段。
运维手册与技术白皮书
运维手册要定位在熟知所有要素需要时立刻能找到。
故障排查可能更适合放入运维知识库中以问题及处理方式列表体现更佳运维手册是故障排查工作依赖的关联材料无法在运维手册中预见出所有的故障场景。
对于技术白皮书的理解行业技术工作者认为更适用于底层技术应用例如针对一种通信协议、一种存储技术的白皮书更看重于技术原理和规范内容深入且翔实是完完全全的专业技术文件。而对于区块链这种大咖级别主题的技术白皮书则更体现为一种行标甚至是国际标准形式。
应用类系统平台的白皮书更通俗的理解是平台对外发布的标准服务、接入和集成方式供任意开发者在授权方式下以边界严格但实现形式开放的方式进行二次开发或者客户端接入这类白皮书其实就是面向开发者的、高规格的技术手册。
建议技术负责人能够组织、联合各个技术团队每年定义一个年度级别的大版本编制发布一次面向公司的技术白皮书。主要内容可以包括
各类内部标准规范文件接口规范、开发规范、操作规范、数据库规范等等对平台级能力进行高度抽象表达技术白皮书最重要的部分郑重表述平台的容量、TPS/QPS并发性能、SLA平台可用率指标、RT服务响应时间指标等交付及质量方面的统计数据年度发布版本数及对应的需求数量、平均交付周期等
模型与代码的融合
领域模型是DDD的核心架构师在设计模型中包含的想法如果无法在代码中体现模型与代码相脱钩那么如性能、可用、扩展等各类非功能性设计的思考与推演也将无用武之地。因此务必要关注将领域模型融入代码减小代码与模型之间的偏差。
代码包的组织方式不论是分层组织还是分功能模块组织与设计的模块结构相匹配能够突显架构应该将此作为标准的开发规范。
落实架构元素间使用关系的清晰和准确需要关注代码模块结构中的访问限制或者是将模块作为库分发如果这些都无法做到那么可以考虑使用工具来监控这些使用关系的问题。
做好契约式设计在代码中设置使用条件并在运行中进行检查如果违反契约应该抛出错误并终止运行包括对象、服务、线程、进程各种颗粒度都可以采用。
将代码模块升级为组件通过微服务架构进行组件级的调用管理通过容器进行组件级的进程封装和轻量级分发是对模型落地进行管控的良好方式。
除此之外还可以依靠传统的代码评审会来进行模型与代码融合的检查。
顶层设计
在对业务需求的分析基础上必须立体展开为平台尽量多地打标签对这些标签的定义和对问题的解答正是平台架构设计的驱动力。技术架构工作的输出物通俗的理解是“从多个切面、视角、维度对软件平台及所实施系统的丰富表达”。各个切面能表达出来整个平台的架构设计也就出来了。
分层总体架构 分层架构是一种最通用的、在行业使用最为广泛的架构模式尽管微服务思想和分布式架构已经普及相比于国外使用较多的六边形架构范式国内还是最热衷于使用分层架构其特点是简单易懂容易绘制能最大限度地同时表达出用户层、业务功能、技术组件、底层数据、操作系统及基础平台环境等多项内容。
面向领导、商业方、合作伙伴等各类不同沟通对象考虑立项、汇报、基本陈述、培训等各类工作场景唯有此架构表达范式最具通识性。
所有架构主题中分层架构是颗粒度最大的也是应该最先做的。主体内容使用水平分层每层都是水平长方形上层依赖于下层对其提供支撑从上至下形成典型的划分方式。
可以分为
用户层
涵盖所有客户端类型C端移动App、小程序、PC端浏览器等
网关层也可定义为接入层
主要表达产品输出的形态描述网关系统、API、文件传递等各种接入方式描述用户层接入的网络链路包括互联网、专线等描述网关层的定位和功能职责如服务发布、接入者身份认证、密钥分发、协议转换、请求路由分发、流量控制等
应用层
即为应用系统层也称之为业务逻辑层。
描述平台要实现的若干个系统或模块可以按照DDD分类方式分为核心域、支撑域、通用域三类。
应用层是总体框架中最重要的一层是其下面各层的产物对其上的用户层提供业务服务在此表达整个平台最终做出什么产品和业务服务。
技术能力层
技术能力层又称为共享的或公共的技术组件层。这是逻辑角度的技术架构核心在这一层需要体现平台的技术组件可以包括消息通道、日志服务、搜索服务、脱敏加密、规则引擎、BI报表、指标计算等通用基础技术的封装和输出以及如文本解析、图像识别、语音处理、实时视频等平台业务所需的特定组件服务。
如果说应用层是分层架构中的最重要的角色那么组件能力层则是架构师工作的最重要的领域作为全平台的技术共享中心是所有技术组件、业务组件的制造车间。
外联服务层
包括技术类和业务类两类外联服务。
一是描述平台访问的技术类三方服务包括邮箱、短信类服务等
二是描述平台对外访问的业务合作伙伴端提供的服务例如支付服务等。
例如平台支付服务连接到银联、网联或者××银行这样平台的全部业务合作伙伴会一览无余。
中间件层
描述平台运行所依赖的各类技术中间件包括使用的应用容器及环境主要的通信协议、缓存、负载均衡、应用配置和服务注册、大数据处理软件等。
因为数据的核心地位很多分层框架会为数据库划分出单独的一层即数据持久化层来重点表达数据和文件存储。
平台能力层
如果使用××技术的云平台应该在这里表述并在这里提供原生能力例如内部网络划分、资源管理及容器、服务编排、灰度发布、服务降级能力。
其他板块
在左右尽量增加几个竖直长方形将运维、测试和管理板块的信息一并装入使得总体架构更加全面。包括使用的代码仓库、构建和发布工具、代码检查工具、文档知识库、项目管理工具、测试工具。
交互关系设计
交互关系设计按照颗粒度和目的不同可以分为“交互流程设计”和“系统逻辑关系设计”两类。交互关系设计侧重于反映相干系的各个角色、各端之间的业务功能联系技术关系并非其要点。 交互流程图设计
交互流程图本质设计的是业务处理流程包括各个环节点流程处理点以及处理点之间的时序交互关系。
交互流程的最佳实践一定是以用户访问开始以服务完成终止。
一个交互流程图所包括的交互环节的数量应该适中2030个是个讨人喜欢的数量。
除了使用泳道图外还可以使用称之为立体图方式的表达交互流程。 泳道图示例 立体图 立体图细节 系统逻辑关系设计
系统逻辑关系作为另外一种交互关系表达方式描述平台内各个应用系统之间的业务接口服务调用关系对技术类例如加密机系统和共享技术能力如短信通道的调用不必纳入其中。
系统间服务接口众多没有制式可参考一般为自由发挥的立体图绘制门槛比较高建议在能力、资源允许的情况下设计和维护一份。还有一种办法是将颗粒度由应用系统提高到板块维护板块间存在的接口调用关系板块的划分基本可以与业务产品条线相对应即将同一个业务条线下的应用系统归为一个板块。
数据架构设计
平台顶层的数据架构首先关注划分区域以数据区域勾画出整体结构性划分区域所体现的分而治之的思想是多数架构主题设计的第一原则。数据架构是一个庞大的设计体系包括业务面、技术面和管理面每个方面都是高度立体化的具体分为逻辑视角和物理视角不难理解逻辑视角面向业务主题物理视角面向技术和实现物理视角是对逻辑设计的技术实现。
业务视角设计
1、划分各个数据大区
完整平台的数据区域可以包括联机业务处理和交易类数据区如客户、商户、订单、支付、业务支撑与管理类数据区如计费、风控、客服、数据服务类数据区如数据推荐、数据管理类数据区如数据治理以及涉及的其他资源数据区如某行业数据某公开的服务数据等等。
2、描述数据主题间的逻辑关系
基于业务视角描述各个数据主题在平台各个系统区域之间的逻辑关系以及流转处理方式。
3、进行 ETL 功能设计
对交易类的数据和用于分析、统计类的数据进行分区治理规划使用不同类型的数据库两区间设计详细有效的数据抽取、传输、转换过程。
4、分层规划数据仓库
分层规划数据仓库主要指数据仓库分层设计一般包括操作数据存储(Operational Data Store,ODS)层、数据仓库(Data Warehouse,DW)层、数据集市(Data Mart,DM)层。数据仓库和ETL(Extract Transform Load)两者之间需要做衔接与融合
5、体现数据管理
数据管理包括数据可视化运营、数据共享、数据权限管理体现数据分级分类管理内容。
6、体现数据治理
低阶的数据治理包括元数据管理、数据标准、数据质量、数据资产管理高阶的数据治理应该包括数据标签、数据图谱、血缘关系甚至是数据沙箱等内容。
工程技术架构
工程技术架构的核心在于设定各大领域所使用的开发框架和各类技术栈以及所用技术与工程或者应用系统的结合。
流量分布设计
流量分布是最能体现美学的平台架构主题在双中心一般指主备机房甚至多中心平台上更为重要流量之于平台等同于脉络之于人体清晰掌握平台的流量分布等同于医生听心号脉是各类平台运维工作的重要基础。
此流量是业务请求所产生的“技术流量”即各系统节点间的调用量。可以叫作链路流量。
链路量的计算方式如下 水平方向 来看可以分成两段第一段是平台入口到应用网关之间第二段是从应用网关进入应用系统区内。 垂直方向 选择合适的颗粒度将全平台业务板块、功能纵向拆开单位时间内某个或某些页面、某个或某些API的访问量多大。对于每个纵向单位以业务访问量开始对完成这个业务请求所访问到的所有应用节点逐级展开计算其向下过程中的每一次跨节点调用。
链路轨迹上的流量单位不是带宽而是调用次数。
应用部署设计
部署架构侧重于从逻辑角度描述各级系统的落地模式即应用系统与平台运行环境的结合用于应用运维人员和运维相关工作场景使用。应用部署架构不是真正的物理架构服务器与虚拟机、网络设备等详细的物理信息不需要直接体现到应用部署设计输出物中。
系统通信设计
通信设计具体指平台各个应用系统进程之间使用的通信网络、通信方式及所用协议。
这里所谓的“网络”定位于应用系统通信所使用的网络信道、地址和网络服务并不包括网络工程如物理网络、交换机路由器网络设备配置、防火墙策略等方面的内容。
应用安全架构
安全治理
安全治理主要指安全组织和考核评价体系以及安全培训、安全保险、合规安全管理。
安全管理
安全管理主要指安全制度体系、员工安全意识和能力建设、系统全周期从需求分析到上线、运维的全部流程安全管理、数据使用申请、存储、传输介质、销毁等安全管理以及安全事件管理。
安全技术
安全技术主要包括应用安全、网络安全、主机安全、数据安全以及办公安全和运营安全等内容
安全审计
安全审计主要包括安全监管、合规审计、风险评估、运维审计等内容。
各种应用安全保障技术措施的运作机制和工作开展策略可以归为以下三种类型
实时防护规则相对固化
如程序加固、接入身份认证数据传输与存储加密
监测识别重于模型与策略能力
一是态势感知做一份流量镜像监测其安全性二是风控预警将业务请求输入风控模型进行分析处理达到安全阈值设置时进行预警触发处置策略。
主动攻击检测技术与评估
即安排漏洞扫描、定期检查、攻防演练等工作并建立相应的如黑客攻击安全技术专业能力和工具。
日志体系设计
日志是系统运行过程中变化的一种抽象其内容为指定对象的操作结果按时间的有序结合。日志之于系统可比喻为地下管道之于城市地下管道表面上看来并不代表城市的建设水平但是暴雨会说明一切。
日志承载着所有文本类数据具有极高的可靠性写日志失败的风险几乎低于所有其他类型的系统操作。作为平台运转的基石从全局视角建立日志中心是中大型分布式应用平台的必然趋势。
日志分层分类
1、业务日志
2、监控日志
3、系统日志
4、控制台日志
还要考虑日志的聚合与使用
建立日志中心的最大目的就是将日志聚合后集中在一个窗口进行查看可解决频繁登录各个系统节点控制台窗口的安全风险和操作复杂问题。
运行保障
高可用体系设计
(1)全链条冗余机制。
有多路可选一路有故障时进行及时自动切换或者故障隔离不影响整体服务。
(2)防御和降级能力。
对平台进行适当保护能够将很多场景问题控制在有限的范围内不至于成为故障。
(3)应用发布保障。
通过灰度发布机制避免应用自身问题造成的平台故障。
(4)应用高性能设计。
指能够应对大的压力在高压下仍能保持正常的响应时间。
冗余机制的设计
冗余是有A和B两个选择A不好用了就切换到B反之亦然在不考虑A、B切换中间的那段时间的情况下平台承载的业务及客户侧体验并没有受任何影响或者说影响可以忽略不计
而防御是只有一个A,A不好用了就让它变成A-以A-的形态来支撑业务使用A-的这段时间部分流量无法得到处理或被拒绝平台提供的服务是打了折扣的。
冗余机制设计的几个方面
多节点负载探活
最为熟知的高可用技术部署方案是“负载均衡应用系统的多节点水平部署”负载均衡具备节点探活能力将接收的业务请求按照负载规则一般包括三种规则分别为依次轮询方式的平均分配、随机分配或者按固定比例分配发送到“活的”应用系统节点。
故障隔离机制
故障隔离机制是对简单的、水平冗余的多节点探活机制的封装、升级模式将有前后调用关系的一组应用节点组成一个单元格对一个应用的探活变为对以单元格为单位的探活对不可用单元格进行封闭不再派发流量。例如A、B、C三个应用系统级联调用A部署6个节点B部署12个节点C部署6个节点可以以2个A4个B2个C为一个单位定义3个单元格负载高可用由节点升级为单元格。
主备节点实时切换
没有条件做多节点负载探活的情况下可以利用由Keepalived实现的Web服务高可用方案来避免单点故障。一个Web服务至少会有两台服务器运行Keepalived一台为主服务器(Master)一台为备份服务器(Backup)但是对外表现为一个虚拟IP。这是更为古老的冗余部署机制但仍然有效。Keepalived所使用的VRRP协议其目的就是为了解决静态路由的单点故障问题。
应用服务双路
应用服务视角的冗余需要通过自行开发来实现核心思想很简单以短信通道为例选择两家服务商应用系统实现双接入不能只选择一个通道吊在一棵树上。
应用双路是广泛使用的设计方式更为常见的是资源连接例如在双活中心下应用系统连接Redis的配置串、连接MySQL的JDBC配置串配置的是主地址和备用(StandBy)地址由应用系统负责探活实现对资源访问的高可用。
微服务的注册、发现机制
使用微服务分布式开发框架或者使用如ZooKeeper等框架提供的服务注册、服务发现机制实现多节点之间的微服务调用治理将不可用节点踢出列表确保服务间调用时选择可用节点。
微服务的注册、发现机制提供的对多个节点服务的可用性管理不仅是冗余同样是一种支持高性能的机制与多节点负载探活的不同在于微服务侧重于开发框架自身提供的负载和调度能力。
建设容灾中心
容灾中心是最大颗粒度的冗余方案也可以称其为最极端情况下的运行保障兜底机制用于应对地震、城市电力故障等其他方案无法覆盖的灾难级情况容灾可以分为双活、主备等多种模式。
防御降级设计
防御体系用于平台性能或者某链路出现卡点无法满足全部的外部流量请求时进行的自我保护方式手段包括限流、熔断、挂维护、超时关闭等策略。防御可以让平台能够避免雪崩即时自愈损失最小化。
限速机制
在流量入口处控制客户端请求接入的速度对超出速度的拒绝服务。
熔断机制
在各服务流量入口处抽取一定比例的请求作为样本计算开始接受到返回结果为止的时间如果其中有一定百分比如50%的响应时间大于设定的平台服务响应时限互联网平台一般为810s则说明该服务不可用立即拒绝服务一般持续周期为30s周期结束后自动打开如此反复按照周期为单位不断进行。
服务维护
平台高压力下关闭低优先级非核心、可被降级的服务实现机制一般为挂维护方式被挂维护的入口链接等于临时被屏蔽下线或者客户单击时通过弹窗提示系统繁忙或维护中应该有维护时间说明。这种方式是一种垂直的服务维护机制。
还可以提供水平的服务维护机制一个服务的后台应用有10个水平部署的节点平台高压力下可以设置让两个节点不响应业务向前端页面或者API网关返回系统繁忙或维护中的响应码。
简单总结下垂直维护是关掉所选的服务水平维护是关掉所选比例的流量。当然可以有最佳的服务方案那就是垂直水平的服务维护模式以便可以实现关闭哪些服务的多少流量这样精细化的维护能力。
超时关闭
一个请求的完整处理一般包括多个系统之间的级联调用也即日志体系设计中所讲的链路概念链路中包括内部各个系统之间、系统对数据库或外部第三方系统的调用每个系统均应设置调用的超时时间一般为3s超时则断掉连接从而尽量保护系统端口不被大量的TCP/IP死链接压死让系统能自愈。
功能降级
低级别功能和辅助类功能很多由独立部署的系统或者调用第三方系统接口实现故障率不比核心功能低对此可以考虑使用预设的“挡板”来进行降级用于临时救急不可因此类功能不可用将整体功能阻塞引起客户投诉。例如广告服务加载失败可以用一个固定的静态页面替代。
弹性伸缩
弹性伸缩包括弹性扩展和弹性收缩。弹性扩展也就是流量压力大、服务响应时间变长时自动化水平扩容而弹性收缩指流量下降时能够自动减少节点数量回收多余资源节约平台占用的服务器总体成本。
总体而言自动防御的思想精髓是“缓释”即在入口处遮挡同时在内部通过释放连接或者扩容等方式来恢复。
发布保障
1、使用工具进行自动化部署
2、分步分批与灰度发布
应用程序部署并不等同于发布部署指技术上线发布是真正的业务上线也就是放开流量。部署和发布在操作上可能是连续一体的但是存在巨大的含义差别这里也是真正发布前的最后一道保障屏障。
核心思想是分步分批进行先部署一部分节点如10个节点选择2个进行发布也就是说承接流量生产验证无误后再部署发布其他节点。
灰度发布首先要圈定灰度单元格灰度发布的核心是对单元格所管理节点进行部署发布称之为灰度生产环境在流量入口处对流量来源进行逻辑区分如使用请求头中的某个标识字段将指定的流量引到灰度环境以此进行生产验证验证通过后再部署发布全部节点。
3、让程序预热实现平滑上线
以JVM的运行方式来审视程序上线可以发现问题对上线节点放开流量时如果处在业务高峰期大量的访问请求进入新运行的程序会导致同一时刻触发大量Class文件的JIT编译。
综上所述发布应用时需要给节点一个预热过程使其能够较为平顺地完成编译工作方法可以是对于关键应用程序的上线工作选择低流量时间段一般是夜里或者通过负载均衡来控制对新上线节点的流量分发以阶梯状逐步增加以便该节点有一个充分的预热过程。
应用高性能设计
对于高性能设计重点从应用开发的视角来考虑。
异步、缓存、并行是实现高性能体系的3个核心理念机制
异步的效用可以从两方面看一是让主功能不阻塞尽快完成不受拖累二是将串行转化为并行的处理方式
缓存直接增加存取速度
并行则是充分利用计算资源同样的时间做更多的事情重点指资源池、多线程、连接池、分布式多节点同时计算等技术运用。
热数据缓存
介绍一个属于中台应用的性能优化方式——热数据缓存以某网页的销售量排行榜为例所有物品销售量时刻都在变化没有办法事先准备数据此类高频“热”数据热力虽高但其业务属性相对低也就是持久化存储的必要性低应考虑使用轻便的key-value型缓存库也就是“不能让此类业务的客户查询请求直接穿透到数据库中去查询”从而实现极高的查询性能。有销量变化时需要主动更新缓存根据情况可以考虑非实时更新无论如何要保护数据库不受此类业务的冲击。
监控报警体系
平台监控能力建设属于“貌似简单、门槛较低但是想要做好则上限极高”的那类任务。根本原因在于里面除技术外存在长期的摸索过程、指标取舍和调试过程需要在所有方面对系统十分了解否则误报警、漏报警会不时发生。
1、主动轮询模式的监控
主动轮询模式的监控实际属于外挂型探活检测外挂可以是测试团队做的发包器在真实客户的网络环境下模拟客户请求。
如有预算可以采购第三方拨测服务。
2、自动监控之业务监控
一般模式为对实时采集的业务监控日志的处理通过预警指标系统进行报警。
3、自动监控之链路监控
一般有日志采集和进程探针两种模式日志采集模式采集链路监控日志针对其中日志ID的接口耗时时长从技术角度对系统间调用链路进行分段监控根据设定的链路时长指标阈值进行报警
进程探针指在系统中埋拦截器通过拦截器程序获取被观测点的时长等重要监控数据。
4、应用系统健康监控
健康监控模式包括两类一是为每个应用系统均实现自检接口二是在部分场景下可以通过VRRP协议进行应用系统的心跳监听Keepalived即如此。
5、前端页面监控
在前端页面中加载监控脚本记录页面加载和操作请求的响应速度以及AJAX型请求和JavaScript脚本加载的时效和错误率从而监控“页面加载时间、白屏率和白屏时间”等重要的用户端体验指标。
6、资源使用情况监控
这是最基础、最核心的监控方式对于服务器、虚拟机、容器监控项包括CPU和内存使用率、I/O吞吐量、带宽使用量、TCP连接数等。
可用率与容量衡量
平台能力衡量指标包括可用率、并发响应能力值以及平台在数据、线路等方面的最大容量测算。
平台运行中最重要的高可用指标即服务可用率很多平台简称为SLA。
一套应用系统的SLA如果是99.9%那么两套级联系统组成的单元的SLA是99.8%(99.9%×99.9%)三套级联系统的SLA则是99.7%(99.9%×99.9%×99.9%)印证了高性能部署提到的“纵深要浅、级联要少”的原则。
根据服务器和操作系统的可用率A、应用的可用率B可计算出应用系统的SLA(A×B)。
使用了云技术之后第一云资源服务器可用率高于自管理服务器可用率也就是说A提升了第二云原生能力和微服务软件能力带来了应用层面的高可用提升也就是说B提升了。
简言之在保障A的基础上尽量提高B使得实际运行的SLA结果值不低于平台SLA的指标要求。 平台SLA的计算 容量衡量包括用户容量、数据容量、线路容量。
行业里对注册用户数、在线用户数、并发用户数三者之间数量关系的认知是
在线用户数注册用户数×(5%20%)
并发用户数在线用户数×(5%20%)
一个租户的数据量如果是100GB而可以分配的数据存储表空间可用资源一共为10TB那么最大租户量就是100个(10TB/100GB)。
考虑到数据库存储时的物理空间率利用问题应该对租户的数据量进行一定比例的倍数放大个人建议值为1.31.5倍。
线路容量顾名思义是线路带宽能同时运输多少个业务请求。线路容量分为外部和内部外部指互联网带宽内部指局域网内部带宽。
并发性能衡量
QPS(Queries Per Second)意思是每秒查询率指某应用服务每秒能够响应的查询次数用于衡量特定的查询服务器在规定时间内所处理流量的多少主要针对专门用于查询的服务器的性能指标。
TPS(Transactions Per Second)意思是每秒事务数。一个事务是指客户端向服务器发送请求后服务器做出反应的过程具体的事务可以是一个请求或是多个请求并没有严格固定的定义。
TPS和QPS是客户端、服务端都可以通用的指标但是在两者的定义中可以看到TPS更适合描述客户端视角的指标QPS更适合描述服务端视角的指标。
分布式之无状态
作为分布式的三驾马车无状态应用、分布式事务和分布锁是开发应用服务的必备选项。 无状态会话是当代分布式应用平台的典型特征之一需要从全链条审视无状态设计主要包括以下的切入点。
从服务端节点部署视角来看无状态会话:
应用系统节点之间是对等关系与用户的SessionID及会话上下文信息彻底地解耦。
具体说就是用户的一次业务办理流程可能包括多次请求前后步骤是串行关系后一步的输入依赖前一步的结果此时如何实现负载可以将任意步骤的请求分发给应用系统的任何节点呢对此唯一推荐的方案是上下文信息内容脱离节点放在可以高速读取的共享中间件处如 Redis 处。
从客户端与服务端交互视角来看无状态会话
务端不保存客户端状态多数实现方式是服务端进行用户身份认证后为用户生成某种会话凭证即SessionID例如可以是Token令牌等。
从通信协议视角来看无状态会话
从客户端到服务端的每个请求都必须包含理解请求所需的所有信息也就是“无状态API”首先方案无疑是使用Http协议的Restful API.
用户便利性视角的无状态会话
使用统一身份认证实现用户单点登录是典型案例.
架构设计图 偏向中台和技术栈的分层架构示意图 偏重业务域的分层架构示意图 移动应用安全架构示意图 泳道风格交互流程示意图 反泳道风格交互流程示意图 立体风格交互流程示意图 立体风格逻辑关系示意图 分层次风格系统的逻辑关系示意图 应用系统部署设计示意图 数据主题处理关系示意图 数据分区分类设计示意图 罗列型的功能框架示意图 功能与交互混合型的功能框架示意图 前端技术评审表 后端技术评审表 版本发布台账 版本运行台账
