守株阁

from：http://www.blogjava.net/sean/archive/2009/09/28/296825.html 最近围观一本JavaScript的书籍引发的争论，一不小心碰到一篇讲编程语言类型系统划分的帖子，回想起当年还在公司内部的Tech Session上主讲过这个话题，不过只涉及到静态/动态、强类型/弱类型，远没有这位仁兄总结的那么全面。 原文链接http://www.reddit.com/r/programming/comments/63tnv/bruce_eckel_33104_im_over_it_java/c02qx55 不多废话，直入正题： [维度一] Static vs Dynamic Typing静态类型和动态类型，区分的关键点为编译期或运行期确定类型：静态类型在编译期确定，动态类型在运行期确定。静态类型代表 Java、Scala、Haskell动态类型代表 Ruby、Python、Erlang [维度二] Strong vs Weak Typing强类型和弱类型，区分的关键点为运行时是否自动转换到与实际类型不符的类型：强类型要求手工类型转换，弱类型 ...

无人区所有伟大的创新、公司和企业家都不是在既有经验、已有成果之上取得的成绩，而是在毫无经验、毫无基础、毫无积累的状态下取得成功。 所有伟大的机会都来自于未来、来自于未知，而非来自于既有。 什么叫逆向思维？在大家恐惧的时候，你需要乐观，在大家都是乐观的时候，你可能要恐惧，类似于古人曾提及的“乐极生悲，否极泰来”，其实讲的就是这个道理。大众的一个惯性思维是“追涨杀跌”，在大家都认为情况乐观的时候，会引发人们跟风模仿。曾有人以投资为例，大部分老百姓并不懂得投资规律，当看见一堆人跟风投资的时候，你就要非常谨慎，这时候可能正是风险来临的时候。 所以，对我们来讲，在遇到困难时，我们要去思考这件事为什么困难，这困难会持续多久？它是在正确轨迹上的一个困难；还是说这个业务面临一些根本性的挑战，需要一个巨大的变革；还是这条路本身就是一个死胡同？当处于乐观状态时，我们要思考这种乐观状态是否可持续，未来需要做什么才能让这种增长得以保持。历史的无数经验表明，所有的发展都是一种波浪式的发展。可以看到，我们有时候处在一个波浪的波谷，有时候处在一个波浪的波峰，更重要的是，我们要去识别这种波浪是否在逐步升高，而不是在逐 ...

问题定义AP 的出现在互联网浪潮出现之前，企业的数据量普遍不大。通常一个单机的数据库就可以保存核心的业务数据。那时候的存储并不需要复杂的架构，所有的线上请求(OLTP, Online Transactional Processing) 和后台分析 (OLAP, Online Analytical Processing) 都跑在同一个数据库实例上。后来业务越来越复杂，数据量越来越大，产生了一个显著问题：单机数据库支持线上的 TP 请求已经非常吃力，没办法再跑比较重的 AP 分析型任务，在这样的大背景下，于是AP开始从TP系统分离，某种程度上，AP是TP的一个分支。 这等于是在存储层做 CQRS 架构设计-另一种方案是在应用层也设计读写分离的架构。 AP的玩法在这样的背景下，以 Hadoop 为代表的大数据技术开始蓬勃发展，它用许多相对廉价的 x86 机器构建了一个数据分析平台，用并行的能力破解大数据集的计算问题。 TP和AP的联系虽然 TP 和 AP 开始往独立的方向演进，但是他们的核心都是需要处理数据，所以需要将数据打通。业内普遍玩法将 TP 数据通过 ETL 工具抽取出来，导入独立的 ...

前言这两周集中时间间歇性读完了《恰如其分的软件架构》这本书。这本书讲的是架构方法，架构方法是一种思维模型（mind set），这种思维模型叫作“风险驱动模型”。 这本书经我们团队的架构师推荐，列在我们团队的集体书目里很久了。但真正去读它、读完它的人又很少。究其原因，还是这本书的内容以谈概念为主，虽然书中举的例子非常生动，仍然始终无法摆脱“为了谈概念而举玩具例子”的问题-这几乎是所有架构书的通病。似乎正统的架构书籍都不可避免地举一些传统行业或者经典软件（比如很多书籍都会反复出现在“xxx 播放器”）的例子。这些软件架构非常经典，可以只用一些小的组件、场景，就讲清楚典型的组件、模式和架构风格的用处。但没有很深的工程/架构经验的读者读这些书的时候，仿佛重新回到了抄书和念书的大学课堂，对于脱离现实的例子只会产生“左耳进右耳出”的感觉。能够温故而知新，是一本书经典化的特征。而能够阅读非入门级的纯理论书籍，则是一个程序员的认知能力和经验达到了一定程度的特征。我读这本书里很多细节还是很痛苦，证明我还是对于形式化的符号（symbol）、记法（notion）还不是很熟悉，而且对于书中运用的问题解析方式、 ...

EBS 的定义EBS — Elastic Block Storage，简言之就是高可用、高性能、弹性可扩展的分布式块存储服务。对于业务来说，它就是一块磁盘，只不过将业务数据存储于远端网络节点，但是使用方法和体验与访问本地磁盘一样。 EBS 可以作为容器的存储盘，可以解决： 有状态容器的状态存储问题 海量存储问题：邮件系统、监控平台、数据库、用户录音、集成测试平台、MySQL 备份（需要测试 OLTP/OLAP 的交互操作和在线交易性能） EBS 的文件系统结构在EBS分布式块存储系统中，最终存储业务写入数据的服务是ChunkServer。 单机存储引擎位于每个ChunkServer上，业务的数据读写请求到达ChunkServer后，最终通过单机存储引擎与操作系统文件系统交互来写入或读取数据。 业务申请的每一块ebs网络盘在我们的系统里都对应一个Volume。Volume本身是一个逻辑概念，每个Volume被切分成多个Chunk，Chunk最终对应到ChunkSever上文件系统中的一个真实文件，因此我们的单机存储引擎最终会管理这一系列Chunk文件的创建，读写，删除等操作。 Jo ...

介绍下使用到的 Gradle 工具《一篇文章讲清楚Gradle与Gradle Wrapper的区别》 comments： Gradle Wrapper 提供了一种“在本地构建中，使用特定版本的 Gradle 进行构建”的功能。 换言之，对于大多数敏捷迭代的项目而言，应该选择 ./gradlew clean build，而不是 gradle clean build。这样不会遇到 pluginManagement 之类的问题，这样说来，每个项目都是自构建的。 要么 IDE（像 Android Studio）自带 gradle wrapper，要么项目自带一个 gradle/wrapper 文件夹，这个文件夹里指定了 gradle-wrapper.properties。 这个命令专门指定了特定版本的 gradle。-all.jar、-bin.jar、-src.jar 分别代表不同的包。 gradlew是在linux,mac下使用的，gradlew.bat是在window下使用的，提供在命令行下执行gradle命令的功能。-这种 w 的中间层策略，值得我们学习。 每个项目本身都带有特定的 p ...

弹性问题 弹性服务最好和监控服务、限流服务配合。 弹性服务的监控最好低于限流服务的阈值，否则不会被触发。 要注意扩容阈值和缩容阈值。如果有必要，设置阶梯阈值，离正常值越远的阶梯越不敏感，离正常值越近的阶梯越敏感。阶梯越远，弹性的量应该越大。 注意弹性有静默期，注意发布和弹性静默期之间是相互矛盾的，要相互关闭。 如果有压测标记，注意让弹性扩容监控包括/排除压测流量。 任务调度或者特殊的有状态的中间件依赖的分布式节点应该尽量避免弹入和弹出。 慢预热服务-扩容机器服务可用性差问题极少部分依赖缓存预热的业务在接入弹性的过程中，在业务代码配置不合理的情况下，可能出现服务节点启动时服务不可用或性能较差的情况。 出现这种问题可以产生如下情况: 服务节点启动后尚未完全预热，大量流量打入导致服务不可用（TP耗时飙升）。 服务依赖数据源尚未初始化完成，服务节点就已注册至服务治理的命名服务器，开始承担流量，但此时服务处于不可用状态（请求异常）。 机器刚刚扩容出来时cpu.busy指标较高，承接流量后影响服务可用性。 此类问题的根本原因是：服务自身预热工作未完成时，处于服务不可用状态，此时不应该将服务节 ...

大促规划.xmind 活动的定义和特点活动具有大并发、高流量的特点，前期充足的准备是活动顺利完成的必要条件。 准备好完备的保证流程，可以为相关人员提供指引。 基本的保障方案 事前：严格按照保障步骤分工执行，活动要报备，核心链路要梳理，梳理完要评估容量和准备，要治理风险，要准备预案，要建设大盘，准备压测和演练预案，要安排值班。 事中：相关责任方（要分技术负责人和运维负责人，召集相关人员，组成稳定性保障小组）监控线上数据，以线上/线下会议、群聊和电话等多个方式参与值班并及时响应异常事件。 事后：组织复盘，总结亮点，指出不足，沉淀经验。 活动报备要理清活动信息：活动背景、活动时间、用户参与路径、活动链接、活动 玩法、预计UV数、负责人。 核心链路的设计与梳理核心链路的梳理、设计需和活动保障的几个核心要素相结合，核心要素分为：隔离、限流、容量。 隔离：域名隔离、Nginx集群隔离、核心服务隔离、以及其他一些重要服务的隔离。 限流：前端活动业务限流、Nginx限流（HTTP限流）、服务限流（RPC）等。特别要关注接入层的限流能力和方案。 容量：从域名解析到后端存储的系列容量评估和准备，容量无 ...

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

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