十几年国内外软件开发经验,七八年前开始专注于企业应用架构设计。酷爱中国传统文化,从先贤那里汲取智慧,指导自己的工作生活。目前在工作之余,写作《架构之道》系列博文,记录这些与架构设计一起的日子。 时间: 2024-10-12 11:11:08
接上文:<架构设计:系统间通信(30)--Kafka及场景应用(中3)> 5.场景应用--电商平台:浏览记录收集功能 事件/日志收集系统是大中型软件不得不面对的话题.目前第三方业务系统对 事件/日志收集系统 的集成思路主要有两大类:侵入式收集方案和非侵入式收集方案.侵入式收集方案,是指任何需要使用事件/日志收集系统的第三方系统,都需要做有针对的编码工作,这个编码工作或者是新增代码用于调用 事件/日志收集系统 提供的客户端API,又或者是修改已有的代码,以便适应事件/日志收集系统的调用特性. 侵
之前在谈谈架构设计的目的 这篇文章中说过,架构设计的目的就是为了解决软件系统复杂度带来的问题. 但是究竟复杂度有哪些呢?所以今天借此说说软件复杂度的六个来源: 1.高性能; 2.高可用; 3.可扩展性; 4.低成本; 5.安全; 6.规模; 一.高性能 对性能孜孜不倦的追求是整个人类技术不断发展的根本驱动力.例如计算机,从电子管计算机到晶体管计算机再到集成电路计算机,运算性能从每秒几次提升到每秒几亿次.但伴随着性能越来越高,相应的方法和系统复杂度也是越来越高.现代的计算机CPU集成了几亿颗晶体管
今天我主要说说架构设计流程,围绕着这么几个方面来讲? (1)识别复杂度; (2)设计备选方案; (3)评估和选择备选方案; (4)详细方案设计; 一.识别复杂度 在如下两篇文章中,我阐述了六个复杂度来源. 文章分别为:架构设计之六个复杂度来源 架构设计之六个复杂度来源(续) 如果不了解架构设计的六个复杂度来源可以参考我的上述两篇文章看看. 从软件层面上来看,前面说过,架构设计的目的就是为了解决软件系统的复杂度.所以我们在设计这个软件的时候,首先需要做的就是分析系统的复杂性.只有正确分析出了系统的
<数据安全架构设计与实战>一书融入作者十余年安全架构实践经验,系统性地介绍数据安全架构设计与治理实践,主要包括:产品安全架构(从源头开始保障数据/隐私安全).安全技术体系架构(构建统一的安全能力中心).数据安全与隐私保护治理(建立全局视野并保障数据安全落地). 专家评论 数据安全问题其实一直存在,只是在大数据.基于大数据的人工智能时代变得更加重要,郑云文的这本<数据安全架构设计与实战>在覆盖信息安全.网络安全基础知识与最佳实践的基础上,对数据安全相关问题有更深入的探讨.如同书中的观
@来源于QCon某高可用架构群整理,整理朱玉华. 背景:有某个朋友在朋友圈咨询微信红包的架构,于是乎有了下面的文字(有误请提出,谢谢) 概况:2014年微信红包使用数据库硬抗整个流量,2015年使用cache抗流量. 微信的金额什么时候算? 答:微信金额是拆的时候实时算出来,不是预先分配的,采用的是纯内存计算,不需要预算空间存储.. 采取实时计算金额的考虑:预算需要占存储,实时效率很高,预算才效率低. 实时性:为什么明明抢到红包,点开后发现没有? 答:2014年的红包一点开就知道金额,分两次操作
1.mysql基本介绍 mysql支持多线程高并发的关系型数据库; 数据库存储引擎InnoDB.MyISAM; mysql快速崛起的原因就是他是开源的; 性能一直是mysql自豪的一大特点; 2.mysql架构组成 麻雀虽小五脏俱全,mysql虽然简单但其内部结构并不简单; mysql物理文件组成之日志文件: 错误日志error log这里记录mysql运行时严重的警告和错误,以及mysql启动和关闭的日志信息 二进制日志 binary log 记录mysql运行时所有的query和query执
1.1 什么是游戏策划 游戏的目的就是通过玩来获得娱乐,因此,设计游戏既需要艺术家一样的创造力,也需要工程师一样的精心规划.游戏设计是一门手艺,就像是好莱坞的电影摄像或服装设计一样.一个游戏既含有艺术要素,也含有功能要素:它必须能给人以美的享受,同时又必须能很好地运行,让游戏者享受到快乐.具备这两种特点的游戏才是好的游戏. 1.2 游戏策划的任务 游戏策划根据自己的创作理念,结合市场调研得来的数据,参考其他开发人员的意见和建议,在开发条件允许的基础上,将游戏创意以及游戏内容和规则细化完整,形成策
================================ (接上文<架构设计:系统存储(7)--MySQL数据库性能优化(3)>) 4-3.InnoDB中的锁 虽然锁机制是InnoDB引擎中为了保证事务性而自然存在的,在索引.表结构.配置参数一定的前提下,InnoDB引擎加锁过程是一样的,所以理论上来说也就不存在"锁机制能够提升性能"这样的说法.但如果技术人员不理解InnoDB中的锁机制或者混乱.错误的索引定义和同样混乱的SQL写操作语句共同作用,那么导致死锁出现的
(接上文<架构设计:系统间通信(31)--其他消息中间件及场景应用(下1)>) 5-3.解决方案二:改进半侵入式方案 5-3-1.解决方法一的问题所在 方案一并不是最好的半侵入式方案,却容易理解架构师的设计意图:至少做到业务级隔离.方案一最大的优点在于日志采集逻辑和业务处理逻辑彼此隔离,当业务逻辑发生变化的时候,并不会影响日志采集逻辑. 但是我们能为方案一列举的问题却可以远远多于方案一的优点: 需要为不同开发语言分别提供客户端API包.上文中我们介绍的示例使用JAVA语言,于是 事件/日志采集