《架构师 2018 6月刊》笔记

现在的时代本来就是终身学习的时代，不光是领域知识，连常识都在不断更新，你不去更新自己的知识，那只有落伍。
不过，学习有技巧，可以学的快一些，学的轻松一些。
这个技巧指的是两方面：

• 一个是学会学习。
• 另一个是掌握核心知识，每个领域的核心知识没有那么容易被替代。

焦虑是这个时代的常态，学会与它为伍，这是你第一个也是终身都需要去学习的。

Google 力推的那些前端技术，最近有何进展？

Service Worker：
Service Worker 是近年来Web 最大的改进之一，它是Chrome 团队力推的一个Web API，它将开发人员从页面的生命周期中解放出来，运行于浏览器后台，可以控制打开作用范围下的所有页面请求，使Web 应用程序能够脱机工作。

WebAssembly：
WebAssembly 使网站能够运行用C 或C ++ 等语言编写的高性能低级代码，为Web 打开了新世界。

例如，你可以创建一个如下所示的按钮组件，然后通过代码 <icon-toggle></icon-toggle> 来使用：

如何做好文本关键词提取？从达观数据应用的三种算法说起

• 基于统计特征的关键词抽取
• 基于词图模型的关键词抽取
• 基于主题模型的关键词抽取

1. 基于统计特征的关键词抽取算法

利用文档中词语的统计信息抽取文档的关键词。通常将文本经过预处理得到候选词语的集合，然后采用特征值量化的方式从候选集合中得到关键词。

• 1. 基于词权重的特征量化
     基于词权重的特征量化主要包括词性、词频、逆向文档频率、相对词频、词长等。
• 2. 基于词的文档位置的特征量化
     这种特征量化方式是根据文章不同位置的句子对文档的重要性不同的假设来进行的。通常，文章的前N 个词、后N 个词、段首、段尾、标题、引言等位置的词具有代表性，这些词作为关键词可以表达整个的主题。
• 3. 基于词的关联信息的特征量化
     词的关联信息是指词与词、词与文档的关联程度信息，包括互信息、hits 值、贡献度、依存度、TF-IDF 值等。
     我们介绍几种常用的特征值量化指标。

• 1.1 词性
  词性时通过分词、语法分析后得到的结果。现有的关键词中，绝大多数关键词为名词或者动名词。一般情况下，名词与其他词性相比更能表达一篇文章的主要思想。

• 1.2 词频
  词频表示一个词在文本中出现的频率。一般我们认为，如果一个词在文本中出现的越是频繁，那么这个词就越有可能作为文章的核心词。

• 1.3 位置信息
  一般情况下，词出现的位置对于词来说有着很大的价值。例如，标题、摘要本身就是作者概括出的文章的中心思想，因此出现在这些地方的词具有一定的代表性，更可能成为关键词。

• 1.5 词跨度
  词跨度是指一个词或者短语字文中首次出现和末次出现之间的距离，词跨度越大说明这个词对文本越重要，可以反映文本的主题。一个词的跨度计算公式如下：
  

  一个词的跨度计算公式

基于统计特征的关键词的重点在于特征量化指标的计算，不同的量化指标得到的结果也不尽相同。同时，不同的量化指标也有其各自的优缺点，在实际应用中，通常是采用不同的量化指标相结合的方式得到Top K 个词作为关键词。

2. 基于词图模型的关键词抽取算法

基于词图模型的关键词抽取首先要构建文档的语言网络图，然后对语言进行网络图分析，在这个图上寻找具有重要作用的词或者短语，这些短语就是文档的关键词。
语言网络图中节点基本上都是词，根据词的链接方式不同，语言网络的主要形式分为四种：

• 共现网络图
• 语法网络图
• 语义网络图
• 其他网络图。

在语言网络图的构建过程中，都是以预处理过后的词作为节点，词与词之间的关系作为边。
在语言网络图中，边与边之间的权重一般用词之间的关联度来表示。
在使用语言网络图获得关键词的时候，需要评估各个节点的重要性，然后根据重要性将节点进行排序，选取 Top K 个节点所代表的词作为关键词。
节点的重要性计算方法有以下几种方法：

• 2.1 综合特征法：从网络的局部属性和全局属性角度去定量分析网络结构的拓扑性质

  • 度：与该节点直接向量的节点数目
  • 接近性：节点到其他节点的最短路径之和的倒数，表示的是信息传播的紧密程度
  • 特征向量：一个节点的中心化指标应该等于其相邻节点的中心化指标之线性叠加
  • 集聚系数：它的相邻的节点之间的连接数与他们所有可能存在来链接的数量的比值
  • 平均最短路径：节点的所有最短路径之和的平均值，表示的是一个节点传播信息时对其他节点的依赖程度

• 2.2 系统科学法：思想是节点重要性等于这个节点被删除后对于整个语言网络图的破坏程度。重要的节点被删除后会对网络的呃连通性等产生变化。如果我们在网络图中删除某一个节点，图的某些指定特性产生了改变，可以根据特性改变的大小获得节点的重要性，从而对节点进行筛选。

• 2.3 随机游走法：TextRank 算法。

3. 基于主题模型的关键词抽取算法

算法步骤如下：

• 1. 从文章中获取候选关键词。即将文本分词，也可以再根据词性选取候选关键词。
• 2. 根据大规模预料学习得到主题模型。
• 3. 根据得到的隐含主题模型，计算文章的主题分布和候选关键词分布。
• 4. 计算文档和候选关键词的主题相似度并排序，选取 Top K 个词作为关键词。

算法的关键在于主题模型的构建。主题模型是一种文档生成模型，对于一篇文章，我们的构思思路是先确定几个主题，然后根据主题想好描述主题的词汇，将词汇按照语法规则组成句子，段落，最后生成一篇文章。
主题模型也是基于这个思想，它认为文档是一些主题的混合分布，主题又是词语的概率分布。

优秀架构师必须掌握的架构思维

架构的本质是管理复杂性，抽象、分层、分治和演化思维是我们工程师/ 架构师应对和管理复杂性的四种最基本武器。

1. 抽象思维

2. 分层思维

有些层次是纵向的，它贯穿所有其它层次，称为共享层。分层也可以认为是抽象的一种方式，将系统抽象分解成若干层次化的模块。

3. 分治思维

4. 演化思维

架构既是设计出来的，同时也是演化出来的，对于互联网系统，基本上可以说是三分设计，七分演化，而且是在设计中演化，在演化中设计，一个不断迭代的过程。

区块链没有未来，是时候抛弃它了

区块链就是这样的一种技术：“让我们一起来创建一长串小文件，每个文件里包含了上一个文件的散列值、一些新数据和算法的答案，如果有人愿意在他们的电脑上验证并保存这些文件，就奖励他们一些钱”。
而关于区块链的隐喻是这样描述的：所有人都把自己的记录保存在一个不属于任何人的防篡改仓库里。

区块链系统并不能保证人们输入的数据一定是可信的，它只能保证当中的数据不会被篡改。一个果农在芒果上喷了农药，但他仍然可以在区块链系统里记录说他的芒果是完全有机的。一个腐败的政府可以创建一个区块链系统用于统计选票，并给它的亲信偷偷输入额外的数百万张选票。一个获得数字执照的投资基金会仍然有可能错配资金。

使用去中心化的防篡改仓库来跟踪芒果的产地、新鲜度、是否用过农药，看起来像那么回事。但实际上，食品安全法、非盈利机构或政府的检验员、独立的新闻媒体、获得一定授权的举报者、有信誉的食品商店、本地农场市场在这方面做得更好。真正关心食品安全的人不会使用区块链，因为他们认为信任强过无信任。区块链技术已经暴露出它的弊端，将数据保存成一长串小文件与果农是否如实报告芒果是否使用了农药之间并没有必然的联系。类似的，点对点的交互缺乏监管、规范约束、中间人或信任实体，是一种非常糟糕的授权方式。
去信任的项目之所以会失败，是因为它们无法给用户带来真正的好处。信任真的太重要了！在一个无法律、无信任的世界里，自利是仅剩的原则，安全只存在于妄想之中，这样的世界绝对不是天堂，而是藏污纳垢之地。

一个可供中小团队参考的微服务架构技术栈

近年，Spring Cloud 俨然已经成为微服务开发的主流技术栈，在国内开发者社区非常火爆。
我认为Spring Cloud 技术栈中的有些组件离生产级开发尚有一定距离。
另外Spring Cloud 体系还缺失一些关键的微服务基础组件，比如Metrics 监控，健康检查和告警等。

主要包含11 大核心组件，分别是：
核心支撑组件：

• 1. 服务网关Zuul
• 2. 服务注册发现Eureka+Ribbon
     针对微服务注册发现场景，社区里头的开源产品当中，经过生产级大流量验证的，目前只有Netflix Eureka 一个，它也已经纳入Spring Cloud体系，在社区中有众多成功应用，例如携程Apollo 配置中心也是使用Eureka 做软负载。其它产品如Zookeeper/Etcd/Consul 等，都是比较通用的产品，还需要进一步封装定制才可生产级使用。Eureka 支持跨数据中心高可用，但它是AP 最终一致系统，不是强一致性系统。
• 3. 服务配置中心Apollo
     Spring Cloud 体系里头有个Spring Cloud Config 产品，但是功能远远达不到生产级，只能小规模场景下用，中大规模企业级场景不建议采用。携程框架研发部开源的Apollo 是一款在携程和其它众多互联网公司生产落地下来的产品，开源两年多，目前在github 上有超过4k 星，非常成功，文档齐全也是它的一大亮点，推荐作为企业级的配置中心产品。
• 4. 认证授权中心Spring Security OAuth2
     Spring Security OAuth2 是Spring Security 基础上的一个扩展，支持四种主要的OAuth2 Flows，基本可以作为微服务认证授权中心的推荐产品。
• 5. 服务框架Spring MVC/Boot

监控反馈组件：

• 1. 数据总线Kafka
     在监控一块，日志和Metrics 等数据可以通过Kafka 做收集、存储和转发，相当于中间增加了一个大容量缓冲，能够应对海量日志数据的场景。除了日志监控数据收集，Kafka 在业务大数据分析，IoT 等场景都有广泛应用。如果对Kafka 进行适当定制增强，还可以用于传统消息中间件场景。
     Kafka 的特性是大容量，高吞吐，高可用，数据可重复消费，可水平扩展，支持消费者组等。Kafka 尤其适用于不严格要求实时和不丢数据的大数据日志场景。
• 2. 日志监控ELK
     ELK（ElasticSearch/Logstash/Kibana）是日志监控一块的标配技术栈。
• 3. 调用链监控CAT
• 4. Metrics 监控KairosDB
• 5. 健康检查和告警ZMon
• 6. 限流熔断和流聚合Hystrix/Turbine
     Hystrix 已经被纳入Spring Cloud 体系，它是Java 社区中限流熔断组件的首选（目前还看不到第二个更好的产品）。Turbine 是和Hystrix 配套的一个流聚合服务，能够对Hystrix 监控数据流进行聚合，聚合以后可以在Hystrix Dashboard 上看到集群的流量和性能情况。

实现生产级的Migrate 操作