cpuz怎么测试cpu性能_如何判断cpu的性能高低

怎么提高自己的系统设计和架构理论水平？ 　　多看多写多思靠，我一起学习架构知识 　　一、生存法则 　　1.1 影响架构活动成败的要素有哪些？ 　　架构活动就是制定并且交付架构方案的过程。在整个软件架构的活动过程中，我们作为一个架构师，首先要做的就是确定架构设计方案 这个方案需要和企业目标一致，与商业、软件环境相匹配，并且还需要满足各种资源的约束条件。而你作为一个架构师，要在这些方案中找到那个能够最小化资源和成本，最大化商业价值，以及最大化目标用户满意度的方案。最终，你还要组织技术团队交付这个架构设计方案

　　1.2 尊重架构原则 　　作为架构师在设计架构方案和组织架构活动时必须要尊重的一些原则。如果违背这些原则，那么作为一个架构师的生存就会受到威胁 有且仅有一个正确的目标尊重和顺应人性在有限资源下最大化商业价值商业和技术模块的生命周期为企业注入外部适应性在一个相对安全的文化环境中探索未知

　　1.2.1 原则一 架构目标 　　架构规划必须始于唯一且正确的目标，并且这个目标还应该和公司的战略意图相匹配。架构师必须尽量保障整个架构活动有且仅有一个正确的目标，且这个目标必须和公司的战略意图相匹配（降本增效） 从6个方面考虑目标 考虑roi和团队处于的阶段，不同的阶段方案可能粗可能细，可以不完美 新方案的实现成本有多少？新方案上线后带来的短期价值有多大？这个新方案是否可以全面替代现有方案？全面替代的实施成本有多少？全面替代之后，这个新方案带来的长期价值是什么？如果不能全面替代，而是两套方案并存，那么增量的维护成本有多大？ 　　1.2.2 原则二 尊重和顺应人性 　　马斯洛理论之动机越迁， 需求本身没有优先级，而动机存在优先级，需求会触发动机， 但动机之间存在压制和优先级， 人有且只有一个主导动机。这个动机由人的内在需求所驱动，并独占且主导这个人当前的一切意识和行为。直到这个动机背后的需求被完全满足之后，更高层次的动机才可能进入主导位置；

　　1.3 法则二 研发人员的人性需求是如何影响架构活动成败的 　　工作稳定 应对着安全性，而一个人如果想发挥主动性，得现有归属感， 如果安全感得不到满足，势必没有归属感，就不会有自我实现 安全感分为生理需求和心理安全需求，心理安全即对应 如何设计微服务的粒度保证心理安全： 1.单从人性角度思考，如果你独立负责一个核心微服务的话，那么你的安全感和自尊都是最大化的（民工分到了自己的地） 2.从研发 ROI 的角度来思考微服务粒度的问题，一个人负责一个效率最高，质量最好 3.我们还可以从微服务本身的设计出发来思考。微服务的核心价值在于以下几点： 粒度小，单个服务可以紧贴业务快速迭代； 去中心化组织和部署结构，减少不必要的协同； 数据和商业逻辑受同一个服务控制，从而在商业逻辑快速变更的同时，保障数据模型的一致性； 数据和状态独立封装，保障一个业务快速演变的同时，还不污染其他业务； 服务本身的独立部署能力使得容错和容量弹性最大化； 细粒度服务发布回滚和故障响应能够有效隔离，出了问题可以迅速降级或回滚 增长飞轮

　　1.4 法则三 架构师如何找到自己的商业模式 　　商业模式（Business model) 就是讲一个企业是以什么样的方式赚钱的，比如电商行业，有自营和平台两种不同的商业模式 商业价值 (Business value)就是从现金收入的视角看价值创造的过程 技术人员为公司创造商业价值三种方式 实现一个商业模式提升一个商业模式的效率加速一个商业模式的收敛速度 　　商业模式的技术表达公式： 天猫这个电商平台 总收入 = GMV（商品销售总额） * Commission（提成） 天猫平台的一个由算法驱动的购物频道 GMV= 流量 * 转化率 * 平均订单金额 天猫平台某个垂直行业的招商团队 GMV= 日均动销店铺数 * 店铺日均销售额 某个垂直行业的大商户运营团队 GMV= 活动参与次数 * 平均计划销售额 * 计划达成率 无论如何，至少要理解你的团队为什么存在，你的工资收入从哪里来 个人价值提升了 实现了商业模式，或者计划达成率从a%到b% 　　我们研究一家公司的商业模式，就是希望你认真理解自己所处的工作环境。如果你活在一个靠公司拨款而生存的部门，那么你学习到的能力是有限的，因为你们部门从上到下都不是在求生，也不是为客户创造价值，所以你也学不到真正的生存技能 公司真的到了生死存亡的时刻，就只能依靠自力更生的部门了。想想看，这种靠拨款才能生存的部门，还会有保留价值吗 对于一个业务部门而言，存在不一定合理，只有提供稳定商业价值的存在才是合理的。 　　靠对阶段性精确目标的最大化投入来取得进步 　　1.4.1 践行生存法则 第一，你作为一个架构师，在架构设计中要追求商业价值。 我们做性能优化时，不是单纯做性能指标的优化，而是一上来就以提升商业价值为目标。因此我们的优化目标是订单数，而不是一个技术指标 第二，想要创造商业价值，就必须不断度量你创造的增量价值，这样才能确保自己处在价值创造的前沿。并且能够在一个相对未知的环境下，不断寻找自己的增值空间 第三，作为一个架构师，要最小化整个架构活动的成本 第四，做架构和做业务一样，都不能靠饱和攻击取胜，而要靠对阶段性精确目标的最大化投入来取得进步 　　1.5 法则四 研为什么要顺应技术的生命周期 　　架构师做技术选型的时候，必须要考虑到所依赖的商业和技术模块的生命周期； 看不准的原因： 三个人性上的弱点： 1.自我麻痹，以繁忙的重复工作来代替深度思考；畏惧变化，以最小化改变来维持自己的心理安全感；路径依赖，以过去的成功经历来应对未来案例 　　软件生命周期曲线

　　怎样才能避免让一个老的技术和架构侵入到新的体系里来 “低调加物理隔离”。我觉得这也应该是这个问题的答案。那就是把这种新的项目和公司其他部门分割开来。参与的人少一些，时间给宽裕一些，尽量远离公司的核心业务和人群 选择技术判断技术选型评审 当你评审别人的架构选型时，一定要他是否采用了一个已经有规模优势，或者是即将具有规模优势的技术。如果满足，那么这个架构建议基本就是合理的。在此基础之上，你可以再通过其他维度去看架构选型。反之，如果选择了即将失去规模优势，或者不具备规模优势的技术，你就有必要跟他探讨这么做选型是否合理 　　1.6 法则五：架构师为什么要技术体系的外部适应性？ 　　架构师要通过优化架构方案、干预架构活动，以保证最终交付的项目不仅能满足既定目标，还能适应不断变化的外部环境。这个过程有一个总的指导原则，那就是为最终产生的架构设计不断注入外部适应性 　　很多架构师把帮助他人创造价值与自身创造价值这两件事混为一谈，这样做，你就很难提升自己独立创造价值的能力。 　　研发活动就是由架构师主导的架构活动。架构师和研发同学对业务、产品做了一系列的抽象，最终形成由技术驱动的技术产品。比如工作流引擎、风控引擎、策略引擎、算法的特性引擎和标签引擎，都属于这一类产品（从业务活动中抽象出纯粹的技术活动，纯粹的技术活动带来的价值是我们的直接价值） 　　架构师需要在技术层面为整个企业的技术体系注入外部适应性，这才是你独立于其他职能所创造的长期价值，是你有底气的自尊的源泉 　　外部适应性即，扩展性，快速支持新业务； 　　只不过你作为技术人员，要从技术视角去理解业务，并将自己对业务的认知转化成一个技术动作。而这个技术动作，最终会和业务动作、产品动作一起，将企业带到一个更好的生存位置上。这才是真正的业务理解，也是你独立于其他职能所创造的长期价值 技术体系建设 　　1.7 法则六：如何鉴别文化环境是否有利于架构师的生存？ 　　架构师如何在小范围内打造一个友善的文化环境 那就是通过你的行为（Leadership by Example）来影响和打造。你的行为方式往往会影响身边人，甚至是参与架构活动的人 　　对架构师来说，针对每一个问题，你都需要有一个行动点。我现在再把这些法则放在一起。不过这次我建议你细细品味这些法则，从你的注意力、价值创造点和行动点来重新审视这些法则。 第一，审视整个架构活动的方向是否正确。对应的法则是要有一个正确的目标。而你的行动点就是确保目标与公司的战略意图相匹配。 第二，审视参与者动机和用户的需求是否合理。对应的法则是不要搭没有人性的架构。而你的行动点就是在方案设计和架构活动组织中充分考虑研发和用户的人性。 第三，审视你的技术是否能够创造商业价值。对应的法则是要有自己的商业模式。而你的行动点就是在一个有限资源下最大化商业价值。 第四，从技术和商业视角审视架构方案是否合理。对应的法则是注重商业和技术的生命周期。而你的行动点就是选择已经有规模优势或者是即将有规模优势的技术。 第五，在变化的环境中审视你的行动。对应的法则是追求外部适应性。 而你的行动点就是干预架构活动和设计方案来不断地注入外部适应性。第六，审视你是否拥有安全的架构探索的环境。对应的法则是构建或寻找一个友善的环境。而你的行动点就是在思想上要包容和求真，在行为上要有良知和勇气，最终达到知行合一的形态。 　　其他摘录 一个架构师，“知”是他对世界的建模、认知。“行”，是他做架构时所秉承的理念、具体的实现 你吹出去的牛或者定的目标，它的可实现性和可衡量性，投入的成本和收益 抓重点的能力很重要-提效手段 往往都是在想什么最值得干，什么是最正确的。这也是我们第一模块里讲的，先找到一个正确的目标，然后对正确目标做最大化投入 　　如何做区域划分： 设计模式是一类为了解决复杂问题而提出解决方案 而设计模式的本质是变与不变分离，不变的逐渐成为组件，变化的遵循设计原则；业务上不变的组件比如数据库、中间件 能够实现复用； 变化的 依赖一些原则进而提升可扩展性、可读性，降低腐化速度； 而微服务划分的依据是分而治之和边界控制； 面向对象的思维找出主干行为逻辑和承载行为的模型以及其他的分支逻辑，模型分离分治 　　二、创建价值 　　2.1 环境搭建（团队氛围）&人力资源 　　构建团队原则并书面化（可以团队会议共同约定并书面化）原则可以用来做价值判断； 架构原则：尊重规则而不是尊重权威；原则是用来解决冲突问题的原因 价值可以用来最小化的资源 　　亚马逊客服团队原则： 人性善：相信大多数消费者不会占企业的便宜，也相信客服同事做事是讲究原则的。选择信任：企业选择无条件信任客服同事和消费者，而不是等待他们通过工作赢取公司的信任。这是个预先授予信用的过程。不对抗：企业和投诉的消费者不是对抗关系。如果消费者投诉了，那么不要先从消费者身上找问题，而是从企业自身角度找问题。看看企业的服务、产品、技术和商品出了什么问题，而不是从风控视角来看消费者是不是一个欺诈型的买家。 　　2.2 正确的目标 　　架构师没有权力定义目标，但却有权力验证目标的正确性和合理性，进而将架构项目引导到一组正确的目标上去 目标正确性：站在企业决策者的角度去思考目标，从而帮助决策者做出正确取舍。目标合理性：以执行者的角度去审视目标，从而以乐观的心态给团队设置一个能带来成就感的合适的挑战。目标可达性：从赞助者的视角去审视目标的，从而以悲观的心态来确保投资在重大风险发生时也能有回报 　　CTO，并认为自己是技术资源的掌控者，而只是监护人。这些技术资源都要从财务上反算到各个业务部门。从理论上来说，每个业务部门是技术资源的真正拥有者，因为他们要支付相关费用。而我只是被授予信任，来帮助业务部门更好地管理技术团队 　　仅仅会担任大规模技术重构项目的赞助者。对于这种大规模的技术重构项目，我的判断条件是：任何项目必须在半年内拿回投资回报。也就是说我投入 200 人日做重构，那么半年内节省的人力要在 200 人日以上 　　目标正确性 架构活动的目标大多是自顶向下给出的，因而架构师最初拿到的目标往往是模糊的，不够具体。那么在目标确认环节，我们就需要把这个模糊的目标变成一个正确的、满足 SMART 原则的目标 　　很多互联网公司的前景并不明朗。多数时候，架构活动的目标很难被量化预估。这些都没有关系，因为你为架构目标注入科学决策和数据分析这个动作，是极具价值的 　　目标的合理性和可达性 确认目标时只需要和执行者确认一件事：在极限压力下，项目交付时间和 KPI 目标是可以被实现的，重大风险是可控的 　　面临目标不正确、不合理或者不可达，但决策者却一味坚持的情况。绝大多数互联网公司在这方面的原则，都秉持着“可以有不同观点，但必须坚决执行”。这个时候，我们作为架构师一定要充分沟通各个干系方。反正横竖都是一死，还不如顶天立地 　　2.3 项目的风险 　　风险特指有可能带来损失的不确定事件。 四个方面的识别风险： 风险有多大？回报是什么？公司对风险承受度有多大？其他的选项的风险和回报是什么？ 　　可行性探索前的准备工作第一，调查企业对风险的承受度 你的选择，只需要控制在企业或部门的风险承受度以内即可，这是你冒险的上限（识别企业对风险的容忍程度） 第二，调查赞助者对风险的承受度 赞助者的风险承受度往往比企业或部门的承受度要小得多，因此这是你冒险的下限 第三，锁定领域专家 领域专家指那些可以预见单个领域风险，并提供应对方案的人。你期望通过他的经验来帮助自己迅速锁定重大风险，找到最佳的风险预案，并准确评估预案实施的代价 领域专家不好找。找多了，你可能会因为过于风险而做出保守的选择。我建议找一到两个专家就足够了 第四，锁定风险决策的建议者 领域专家不同，这些建议者最好与部门利益绑定比较深，但与架构活动的成败关系不大。我的经验是最好找四到五个决策建议者。人数太多，意义可能不大；人数太少，则可能导致视角不完整 重大风险的发掘 　　项目交付的视角: 当前的时间要求和资源投入，能否产出质量上可以接受的实施方案？ 也就是说，实施方案是否高于质量底线？ 多个参与项目的团队能否有效协同？ 我们是否留出了足够的时间，让团队去处理集成中出现的问题？ 商业价值的视角: 是否存在会大幅影响最终产出的商业价值的因素？比如恶性竞争 人性视角： 整个架构方案是否符合关键研发人员和目标用户的人性 有限资源的视角： 指的是你这个架构活动的最小必需资源是否能够到位，主要包括运营资源、研发资源和技术价值 其他风险： 监管风险、法律风险和安全隐私风险，法律风险，政策风险 　　结论：单个视角梳理出来的重大风险最多不能超过三个 风险发掘要自上而下，提炼 排序，列表将是风险预估的主要输入，我建议数量最好不要超过 5 个。 　　小结： 在这个过程中，行王道的做法就是找到那些具备高质量思考和丰富经验的人，让他们从各自的视角出发去发掘重大风险。然后在他们思考的基础之上，你需要迅速迭代自己对风险的全局性思考，不断提升相应预案的质量。 在此之上，你还要形成完整的、全局的、量化的风险评估和重大风险列表，并及时与执行者、赞助者做沟通。最终，你需要站在决策者的视角上，以相对乐观和敢于冒险的心态，做出可行性的建议。需要格外注意的是，无论如何，架构师都不应该隐瞒风险，绑架其他参与者。 　　三、项目启动 　　3.1 统一语言 　　第一步，发现不同的语境（上下文）第二步，定义概念第三步，语义建模第四步，讨论修改第五步，公布、维护和使用统一的语境 　　3.2 项目启动 　　目的 项目启动的真正目的，是让所有参与方完成一次有约束效应的目标与任务确认 道 项目启动环节的王道是以终为始，公开架构活动的明确目标，以清晰的语义阐述参与者的责任、权利和架构环境，保障参与者对目标的全力投入。那么架构师，就需要设立保障机制，来保障这个合同是真实有效的，从而最大程度地提升架构活动的成功概率 项目启动前的准备工作 1.资源环境：确认并锁定运营资源、产品资源、技术资源和数据资源 2.架构环境：将之前搭建的架构环境，尤其是架构信条的细节，整理成完整的线上文档，并共享给其他参与者 3.架构文档：完成整体的架构规划，初步完成不同领域的细节规划文档 4.重大风险：梳理好整体和各个领域的风险，完成已知的重大风险预案 　　问题&答案缺乏问题升级机制和冲突解决机制：在互联网这种舍命狂奔的状态之下，缺乏这种机制的架构项目，注定会在众目睽睽之下以崩塌收场 2.缺失技术细节：多数沟通停留在口头，设计文档不存在或者不完整；核心领域和强依赖中有大量仍处在争议状态的设计评审结论。 3.架构方案互相冲突：整体的架构方案，跟一个或者多个细分领域的架构方案有冲突 4.隐藏的技术风险：多数互联网公司不怎么区分大项目和日常需求，导致对大项目的技术风险评估过于简单和乐观。而这些大的项目，可能会因为系统复杂度高而导致失败 5.资源不确定，某几个领域的资源无法保障 100% 的投入，只表示“尽力而为”。 6.边界模糊：部分执行团队之间的任务边界模糊，这也是第 26 讲提到的任务边界划分尚未完成的情况 　　答案 我们做取舍的原则是以保障用户价值和商业价值为前 　　3.3 高价值的交付 　　架构活动不仅庞大，任务也错综复杂。不过它也符合二八原则，即：最具商业价值的占比基本不会超过 20%。而我们架构师的目标就是找到那些 20% 左右的高价值用户点，确保这部分的交付万无一失 　　找出最大的价值，最先交付

　　3.4 设计结构化 　　软件在其设计范围内的设计理念、代码结构和实现方式上是同质的 　　别人写代码就是依照产品需求文档，做个从自然语言到计算机程序的转义。而你出手就不一样了，是一个基于对问题本质、商业价值和软件结构性思考的长远设计！ 　　横向问题： 简单来说就是软件系统内部与业务无关的技术债，比如性能、可扩展性、可用性、可测试性、可维护性和安全合规等问题。这些问题都属于非功能性需求，也就是说，产品经理一般不会把这些问题直接写在需求文档里 　　有能力、自主的人不用太多引导就能产出可靠、高质量的成果 　　四.系统交接方法论 　　系统架构图、核心领域模型核心业务流程、时序上下游系统依赖、核心联系人、协议方式中间件基础资源依赖、基本账号系统操作页面、入口以往大促保障手册、应急预案、资损盘点系统基础监控、业务监控地址遗留线上Bug清单和Owner分配代码权限以及核心L0入口 　　五.架构师的思考力 　　5.1 持续创造增值为目的的思维 　　架构师必须选择一个以持续创造增值为目的的思维。这其实就是我们整个模块的总纲。 　　从模块一的生存法则开始，到模块二对架构活动的规划和干预，再到模块三的架构师的能力维度，我们一直在总结架构师必须要创造的价值，以及创造这些价值的方法。 　　5.2 中台的使用场景 　　中台的使用范围是有限的，仅仅限于技术演化相对慢，且功能通用性高的场景中。过往中台的失败案例，也集中在把中台强推到创新业务中的情况，比如前两年传遍全网的某大厂国际化中台就是典型的例子 　　5.3 跨领域冲突的能力 　　跨域架构师的核心挑战了：要持续抵抗天然的熵增，将多个子领域中不同的设计理念、代码结构和实现方式，往同质的方向上进行整合。 　　跨域架构师的价值在于解决一个复杂组织中必然存在的局部与整体的冲突，最终要从全局层面寻找到最优解 　　总结一下，跨域架构师的存在就是协调子域之间的决策、执行和沟通，从而平衡全局结构化和局部个性化之间的冲突，最终最大化全局目标的实现 　　5.4 架构师成长的必要条件是什么 　　

　　在程序员阶段，主要需求实现的结构化，也就是一个模块内有关业务的部分。兼职架构师阶段，主要模块整体，以及与业务无关的横向问题。跨域架构师阶段，主要不同模块间结构合理性的问题。总架构师阶段，技术架构的长期正确性。CTO 阶段，企业的长期生存。 必要条件之一：思考力，独立思考与决策能力&有效决策有别于其他人的视角；不同的证据组合；不同的思维方式 必要条件之二：信息内化能力 无论是大厂还是小厂，都用不同方式提供了架构师成长的信息优势。大厂更有利于增加深度，小厂更有利于拓展宽度。如果你在大厂里，就要多解决难题，把这种信息优势转化成某个领域的深度。如果你在小厂里做事情，就要把小厂提供给你的信息优势内化成所在领域的宽度。这个过程，会帮助你把外部的信息优势内化成内在的知识优势。当处在一个有相对信息优势的环境中，你又比别人更擅长发现、总结和抽象知识，最终就会形成知识优势 这是一种从大量信息中提炼出知识模型的能力。这些知识最终固化到你脑海里，帮助你的一生 方法论 ==》 模型 必要条件之三：适应力 在不同的成长阶段，根据环境和场景不断调整和扩大自身的能力维度，目标是最大化自己的产出，以及对企业的增值 　　5.5 架构师成长的充分条件是什么 　　大量高风险的决策机会；对架构师友善的环境；正确的目标。 　　，Amundson 没有绝对的领导权，但却有绝对的领导力，而他的领导力就源自一个又一个优秀的决策 　　5.6 去中心化 　　虽然中心化可以让你成为单点，给予你更多的安全感，但实际上也剥夺了追逐更大机会的可能。一旦自己成为单点，现有岗位离不开你，也就无法接触到现有岗位之外的机会了。 　　对于一个架构师而言，只有生存的压力才会刺激你思考出真正有商业价值的架构。在强大的成本压力之下做艰难的取舍，只有少数幸存者才有深刻的体会。

　　去中心化，即多角度思考问题 　　经济学就建立在“人是理性的”这个基本假设之上；经济学就是把人建模成一个最大个人收益的理性个体 　　六、技术预研方法 　　学会用一个技术只是第一步，最重要的是要追问自己： 这个技术解决了哪些痛点？ 别的技术为什么不能解决？ 这个技术用怎样的方法解决问题？ 采用这个技术真的是最好的方法吗？ 如果不用这个技术，你会怎样独立解决这类问题