21 | 高性能设计，一切都围绕着契约精神
该思维导图由 AI 生成，仅供参考
契约精神是高性能架构设计的“拦路虎”
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文以“契约精神”为核心，探讨了高性能设计的关键要点。首先，高性能设计需要清晰定义性能目标，包括系统响应时间、系统吞吐量和系统容量。契约必须明确、具体，才能有效保证高性能设计的实现。有上限的契约才能有效交付，强调了对目标的明确定义和交付给用户的重要性。文章还提出了有上限的契约才能有效交付的观点，强调了对目标的明确定义和交付给用户的重要性。在高性能设计中，对于每个组件/服务都要确定目标，进行设计，然后进行评审和测试，确保满足性能需求。文章还强调了对系统资源的争抢问题的重视，以及隔离和提升架构的可扩展性的重要性。最后，文章提到了全链路生产压测的重要性，以及将业务问题抽象为技术问题的思路。整体而言，本文通过深入讨论契约精神，为读者提供了关于高性能设计的重要思考和指导。
《乔新亮的 CTO 成长复盘》，新⼈⾸单¥59
全部留言(13)
- 最新
- 精选
如水技术行业发展到今天，基本不存在太多的技术挑战了。这句话我不赞同，我还没看到中国有好用的操作系统，这个技术没挑战吗？作者回复: 你好，如水 谢谢分享、讨论。我们一起讨论： 1 中国操作系统的问题是失去的窗口期，造一个好用的操作系统其实并不难，但难得是周边的生态。所以这个问题目前还真不是技术问题。 2 延申出来看，其实比如登月，人工智能，自动驾驶等等，还是有技术挑战的 3 从第二点来看，可以区分为把这个技术作为一个产品，还是使用产品；比如我们是使用云计算产品，还是研发云计算产品，做一个好的云计算产品还有很大的挑战，但是使用一个云计算产品，没有什么挑战了 4 我们的上下文，中国大部分公司还是commerce公司，就是商业公司，其实更多的是使用技术，从这点上来说，基本没有挑战，很多的所谓技术挑战只是在重复造轮子。 5 如果觉得自己技术牛，最好的证明就是创业去开一家公司，把自己的技术做成产品卖出去；否则就是在使用技术，那么能不能用好才是衡量的标准 6 但是，放在不同的公司，有可能因为人员能力问题，这些可能还是技术挑战，这是有可能的。我这里说的是趋势，有上下文，就如同做技术的，一定要有context。 谢谢分享，无私的分享你的观点，一起讨论，共同进步，感谢。
2020-12-14449
李克光"任何复杂问题都可以被拆解为简单问题，只要拆解得足够细致。一定要牢记这一点，这种思维能力是技术人的安身立命之本。" --乔老师很好诠释了《 道德经》中 “天下难事，必作于易；天下大事，必作于细。是以圣人终不为大，故能成其大" 。 非常感谢乔老师的技术传道，让我贯通了很多思路，收获良多。作者回复: 你好，李克光 谢谢分享，这种领悟和分享特别好，还帮助了别人。
2020-12-11211
E乔老师看似在讲架构设计，实际上是在讲技术治理，契约精神是治理过程中的指导思想，乔老师也说到契约不可能无上限，因此本质上依然是在给大家布道“Trade-Off”思想。作者回复: 你好，E 人生永远是在不确定性中寻找确定性，不断的做决策。
2020-12-117
Weehua我也非常认同乔老师的观点：在当今中国的互联网环境中，大部分公司都在使用技术，如何使用好技术我认为没有太大的挑战，我们遇到的坑，遇到的技术问题，大部分都是别人走过的路。2年前，带团队开始从0到1做大数据平台相关建设，其中遇到了很多挑战，最后都是通过各种学习和交流得到了很好的解决。 大部分公司发展很快，还没有到稳定的阶段，分工也不会那么细，所以在技术深度这块我认为是远远不够的。但是到了一定阶段，一定要慢下来，聚焦核心技术，还是要做一些优化的，所谓的技术壁垒，就是一直不断的做这些小优化，量变到质变。作为技术管理者，怎么使用技术，做事的思维和认知感觉才是最难的。作者回复: 你好，Weehua 握手
2020-12-164
leslie其实"高可用和高性能"可以放到一起：本质就是SRE，我们看看京东、阿里的双11其实非常典型的体现了这点。架构代码和架构的代价、硬件基础架构和资源合理使用、业务的取舍和问题的重要性。 可能自己在这条路上用了大量的经历研究：根据业务的合理性与重要性去合理的使用资源，对于不确定性和关键业务可能的问题做好充足的灾难预演与危机应对策略，早年”熔断“被太多各行的人去笑，可是放到今天而言-这种格局之大实在钦佩。自己在某些行业都经历且处理/经历过极限危机，如果当时不曾合理处置对于所在企业就是重大事故。 Google的SRE中的一句话至今提醒这些年的我”没有Bug的程序是程序的特殊状态“，这几年很多人提出过运维无价值时我曾说过一句话”你做不到你的车子不在路上不抛锚，万一这个问题在高速公里上发生时，没有人帮你解决问题难道你要推你的车子下高速么“。 以上是个人对于高可用和高性能的一点薄见：还请老师指正。作者回复: 你好， leslie design for failure是高可用的设计理念，也是人生处世哲学。 分享的特别好，谢谢
2021-03-072
spark对高性能的自顶向下的认知：流量控制、扩容、提升各组件的处理能力 对高性能的分解： 一，架构角度：硬件、异步、中间件、缓存、负载均衡、读写分离，集群，分片； 二，技术角度：网络IO模型、无锁多线程并行、数据结构、算法、网络传输时间、IO时间； 我写代码追求性能最好，至少要比竞争对手好。我们团队有人一个接口2s照常上线，我至少要优化的50ms以内。 从商业竞争角度看高性能，其实高性能不是壁垒，别人很容易超越，例如加个128G内存就可以从2s提升到10ms。作者回复: 你好，spark 专业， 卓越，为你点赞
2020-12-1121
glutton还有一个点需要向乔老师请教，目前技术调整或者是技术壁垒基本不存在了，应届生基本对组件啥的很清楚了。。。 那么，程序员该如何提高自己竞争力呢？听课过程中，有一些点，比如提升认知?改变思维方式?可是感觉又欠缺实现路径。。。作者回复: 你好，glutton T型人才，一定要有自己专业的一个领域，这是一竖； 广度也要有，有专业的领域后，可以向周围延申，不仅仅是技术，还包括软技能，比如沟通能力，决策力，团队管理能力等。 任何事情，认知改变肯定是效果最好的。
2020-12-111
Anyou Liu乔老师，测试环境资源有限，配置不如生产，数据量也达不到生产的要求，往往测试环境没问题的，到了生产环境性能还是有问题，测试环境的指标往往也不能直接类比到生产，有没有什么好的解决办法？作者回复: 你好，Anyou Liu 测试环境肯定资源不能和生产配置一样。 这个时候一种是做好容量规划，测试环境和生产环境和处理有关的参数等比缩小，其他基本参数一样，通过分析进行计算。 第二种是在生产环境进行全链路压测，业界也有这样的工具。
2020-12-1181
adang契约精神正是现在团队缺失的，每年 618、双 11、双 12 公司运维、运营、研发全员戒备监测系统是否有异常，出现异常马上处理，每次大促结束再全员复盘总结，对发现的问题进行修改，下一次再这样循环。据团队老人讲，现在已经好多了，只是不放心所以才全员盯着，基本上不会出现大问题，以前是全员通宵忙救火。即使到现在也没有很清晰的目录，一切都是差不多就行，到时候再说，顶多在大促前预先准备好扩容。 老师说的明确目标履行契约，我的整理是事先要做好明确的分析和研究，把每个细节都考虑清楚，在执行过程中做好监测跟踪，收集反馈并及时做出调整。可很多研发人员和管理者不愿意静下心来细致的思考分析，理由是，想的再细也会有遗漏，太浪费时间，只有真正做了才会发现问题，想的差不多就开始做，做的过程中再调整，才是最快的。结果也就没有了契约精神。 还有一个原因是研发人员对于违约成本没有切身体会，出了问题调整呗，没啥大不了，但是在商业合作方面，这样的事情那是大忌，因为事前没有约定清楚，那么出了问题全是要用钱解决的，所以就特别注意，锱铢必较。这也就回到了老师一直说的，要站在公司发展的角度看问题。作者回复: 你好，adang 分享的特别好
2021-02-21
小乙哥1.契约其实就是业务要求的目标，围绕这个目标，达成结果就是契约精神的体验。 2.具体的实现目标方法论，就是高性能设计的过程。核心是三大步: 保护系统；弹性设计；组建能力建设(这块会包含很多的术，比如分库分表，缓存等)作者回复: 你好，小乙哥 棒
2021-02-07
