守株阁

背景service-centric architecture 以服务为中心的架构，和 SOA 的区别是？ 服务治理的模式server-side pattern：容易集中管控，易单点失败。client-side pattern：不容易集中管控，不易单点失败。 演化流程 基础治理能力：通信协议统一、命名服务的统一、监控预警、运营平台 高性能/易用性：通信框架高性能/通信框架轻量化/分布式链路追踪/测试工具可视化 全方位的治理能力：全链路压测平台/深度服务化 SOA/链路级流量治理/易用化平台构建 业界前言探索：SET 化高扩展架构/云原生架构治理 治理体系该有的治理能力都要有。 注册中心 服务注册 服务概要 提供者 消费者 监控报警 节点监控 性能监控 业务监控 异常监控 服务运营 配置管理 服务分组 节点管理 服务鉴权 数据分析 性能指标 来源去向 主机分析 数据报表 调用链路 关键组件-本地代理比如 LocalAgent，能够做到：策略下沉，解耦功能，对业务服务侵入性低。 但 Provider/Consumer 还需要使用自己的 sdk，它和远端的 naming...

版权归作者所有，任何形式转载请联系作者。作者：二阶导（来自豆瓣）来源：https://www.douban.com/note/635771361/ 這篇筆記按照目前小說的兩位主線人物，即 拉斯柯爾尼科夫 和 馬爾梅拉多夫 兩家人作爲主軸進行區分，隨着劇情的推進，此結構可能會進行調整。 拉斯柯爾尼科夫 相關1 羅季昂 · 羅曼諾維奇 · 拉斯柯爾尼科夫 Rodion Romanovich Raskolnikov (Родиóн Ромáнович Раскóльников)小名叫做羅佳 (Rodya)，或是叫做羅季昂，羅季卡 (Rodka)，窮困潦倒的法律系大學生，男主角 拉斯科爾尼科夫 Raskolnikov 中的 Roskol 意為「分裂」①，指俄罗斯正教会的教派分裂事件②2 阿芙多季婭 · 羅曼諾芙娜 · 拉斯科爾尼科娃 Avdotya Romanovna Raskolnikova (Авдотья Романовна Раскольникова)小名叫做杜尼婭 (Dounia)，或是叫做杜涅奇卡 (Dunechka)，拉斯科爾尼科夫的親妹妹 3 普利赫利婭 ·...

本书不同于《人类简史》和《未来简史》，是探讨当下的重要议题和全球化的议题。其实顶层的议题，和每个人的切身命运，是息息相关的。这本书其实是 21 世纪的 21...

这本书厉害就厉害在，15%以上的内容都是引述的资料，可谓旁征博引。 人类历史上有过以下几个危机：饥荒、瘟疫和战争，都已经被现代文明部分战胜了（或者，至少已经在正确的道路上取得可观胜利了）。 人类已经可以追求长生。现代文明的特点是让人追求快乐。人虽然没有必然享受快乐的权利，但有追求快乐的权利。（智）人类可以通过生物工程、半机械人工程和非有机生物工程，往神迈进。我们得到了神的创造力和破坏力，就可以成为神。神并不全知全能，也不是某种形而上的特质，神意味着超生物的能力。 伊壁鸠鲁告诫自己的门徒，过度追求快乐是危险的。佛教徒认为，追求快乐是痛苦的。快乐本身是来去不定的东西。 21...

本书是历史特写，忠于历史，文辞优美，写出了历史关头，人物的选择。 到不朽的事业中寻找庇护（不朽的逃亡者）：1513年9月25日，富有冒险精神的西班牙巴尔沃亚随船到达南美洲，去开拓和寻找财富，他不仅挤走了整支队伍的主人，还赶走了新派来的总督。但是，被他赶走的船队主人却回到了西班牙，向西班牙宫廷举报了他的恶劣行为。为了避免西班牙宫廷的惩罚，他决定率先去寻找南美大陆的财富，以此来庇护自己的安全，在艰苦的旅途之中，他成为了第一个看到太平洋的文明中的人类，并且他知晓了不远的国度中还有存有无限黄金。而就在此时，他的朋友皮萨罗为了抢夺功劳背叛了他，联合国王派下的新总督一起将其暗算 [1] ...

数据密集（Data-Intensive）与计算密集（Compute-Intensive）是当今两大负载类型。前者以大数据为代表，后者以深度学习和 HPC 为主要代表。 谨以本书献给那些追逐梦想的人们。 另一个电子版本。 前言数据密集型应用要处理的瓶颈往往是数据的规模、数据的复杂度和数据产生与变化的速率；与之对应的是计算密集型应用，CPU 往往成为其瓶颈。 本书是关于数据处理系统及其相关技术的（NoSQL、消息队列、缓存、搜索引擎、批处理和流处理框架）。 每一种技术都基于一定的设计理念，而且只适用于特定的场景。 不要过度优化。 可靠、可扩展与可维护的应用系统现在的典型系统架构已经很明确了，因为业界已经有成功的案例，对这些组件做了很好的抽象，我们只要做好拿来主义就行了。 可靠性（Reliability）fault tolerance 和 resilience 是系统的容错的体现。 硬件故障对于大型 IDC，即使磁盘的 MTTF...

所有的垃圾收集器，都基于弱分代假设。实际的垃圾回收效率取决于堆内对象的分布状况。垃圾回收并不能解决内存泄漏或者应用程序逻辑的不良分配习惯问题，要处理 JVM 内存回收问题的根本方法是对程序进行调优。 有几个常用原则： 减少临时对象，尽量复用内存。 使用对象池。 主动提前释放对象。 主动 gc。 好的代码比 tuning 更重要。 选 gc 算法比 tuning 参数重要，tuning 参数是最后一步。 其他情况，可以通过 tuning garbage collector 来解决。 操作系统的影响 SWAP 可能会显著增加 GC 时间，因为被换出的堆还要被换入。 美团的实践参考： 《从实际案例聊聊Java应用的GC优化》 《Java中9种常见的CMS GC问题分析与解决》 Minor GC Major GC Full GC 垃圾收集器分类 可以看到一个现象：在大部分时候，g1 比 CMS 快，但极端的百分位里，CMS 比 g1...

123456789101112131415161718-- 查看自动提交SELECT @@autocommit-- 查看全局隔离级别和会话隔离级别SELECT @@global.tx_isolation, @@tx_isolation;-- 查看引擎的事务状态，这里可以看出死锁日志，但需要 PROCESS privilege(s)show engine innodb status# 查看表详情show table status like 'dept_emp'# 查看当前存储引擎默认的行格式SHOW VARIABLES LIKE '%innodb_default_row_format%'# 查看全部 binlog 文件show binary logs;# 查看最新的binlog，带有 positionshow master status; # 查看某个 binlog 的内容show binlog events in 'binlog.000156';

背景介绍名词解释ldc logical data centeridc internet data center ldc 是 idc 的进化版，是一种单元化部署方案。 扩展模式 vs 镜像模式扩展模式是把服务/数据库分拆，然后部署到不同的机房里面，相当于放大了一个物理机房。 镜像模式是每个机房里部署的服务都是一样的，每个机房承担一定流量。 镜像模式的容灾效果更好，难度在如何切分流量上。容灾还要考虑机房级容灾、部署地容灾的问题。多地部署带来距离，距离带来延时，延时带来 replica 的风险。 单元化部署所谓 cell，是一个能完成所有业务操作的自包含集合（每个单元，都是其他单元的镜像）。一般的 soa 架构，服务是分层的，而且每一层的任一节点都可以被其他机房调用。而单元化部署的结果是，本单元的上层节点，只会调用本单元的下层节点。它具有一个站点全部的功能，但不具有一个站点全部的流量。 这种单元化部署实际上就要求底层的数据也要做 sharding。单元化的结果是，数据库连接可以更好地被复用-多个单元互相跨 db...

真正的高可用高并发架构，只有在压测中才能显示合理性和不合理性。有时候我们怀疑积压来自于服务，其实可能来自于数据，或者缓存或者消息队列。 确认核心链路的范围：纵向看，深度到哪里（哪里已经不是本架构域需要关注和改造的范围，哪里需要 mock）；横向看，一个请求会涉及多宽的 scope（服务的宽幅）。产出是：需要关注的服务和拓扑结构。 寻找压测指标：容量应该在什么条件下摸到多高。高度由现在的日常业务高峰和大促的流量增长综合评估得出，首先确定业务系统应该支持的 qps/tps 数量。然后考虑容灾等级，即允许在几个机房、几台机器挂掉以后，服务还能正常运行。如果一个服务应该支持的日常峰值（考虑大促），乘以冗余数量（如果是两地三中心，应该考虑将单机房的压测峰值乘以 3）。 确定压测过程中压测指标： VM 性能指标项： fullgc 次数 gc time（总数和平均值） gc count（注意和同环比看是不是显著增加，是不是有可疑的波动） block 状态线程数（看看系统是不是已经达到吞吐瓶颈了） 服务性能指标项： 接口 TP999 的响应耗时（没有办法统计这项指标的可以看 MAX 和...