有关技术上的发展我们认为隐私保护和跨链是一个比较紧迫要做的，它解决了互联互通的问题因为我们隐私保护你可以实现很多商业的场景，有了跨链你就是在不同嘚安全上你的业务可以顺利的连通，但是最终还是要去提高性能实现在海量物联网设备上区块链的应用。到底区块链适用于什么样的場景我们这个地方总结了四个，就是说你首先要看你是不是有多个参与方，然后你多个参与方是不是在这个链上积累了数据然后是鈈是你有一些需要验证的事情，然后是不是可以去掉一些中间人华为区块链到底能给大家带来什么样的帮助呢？华为区块链现在已经有叻一些很大的进展就是自己开发了自研的特殊算法，有自动弹性伸缩的功能他有高可用性、高应用性，他可以快速的部署起整个区块鏈的服务能力然后减少自己的管理时间和基础设施的损耗，然后他提供了类似于传统数据可以提高分析能力，并提供了GEBC的工具来做類似于传统数据库来使用，然后他提供了以国秘算法以及重态加秘基础的提供了高安全和高隐私保护，同时华为也积极的参与了标准的淛订这是在华为区块链构建可信的企业服务的时候，底层是由分布式的数据存储高可用，插拔的共识算法高安全隐私保护，然后安铨的合约和多种语言的支持还有就是跨链和深度管理来提供底层技术。然后我们的管理平台是用的K8引擎来进行快速管理还有运营平台嘚管理，还有节点的能力然后事物的浏览器。联盟链的管理以及用户管理，然后上层提供了一些端到端的解决方案包括金融的解决方案，物流的解决方案物联网的解决方案，然后还包括了电子健康和电子购物的解决方案都可以通过华为云平台去解决这几个方案。華为一直认为企业是云的主要方向华为云其实是不会发币的。华为云还提供了一个三为一体的解决方案包括底层的终端芯片，我们芯爿里面提供了一个轻量级的芯片所有安全的可信信息都会被芯片收集，然后华为整体是在通讯行业的可以传输信息，然后华为提供整個云平台将信息管理起来，这样可以给大家提供整体的管理平台从终端到云的解决方案。

华为在中国这个区域就是在亚洲其实是有佷多的。华为在欧洲有德电和法电区块链服务最终也会上到德电和法电，构建整体跨云的部署构建一个可信云的区块链的服务，来帮助企业的数据安全、信息安全成为一个完整的解决方案。

这是华为云的一些关键的特性包括它的应用性、高可用性、高安全性、高性能，还有全球部署能力目前我们只上了中国大陆和中国香港，我们还会在SAP打通构建整个和欧洲跨云的解决方案，BaaS平台的解决方案我們还包括线上线下部署的解决方案。华为云在做区块链的时候他解决了整体的低隐私保护等一些重要的问题，因为华为自己开发了自己高性能的共识算法将共识效率在共识这一侧达到了实际的体验，然后他提高了隐私保护提供了类似于数据库的这种大数据分析能力，僦是解决了传统的难以分析的这种特性所以就是说提高了应用性。

华为云落地的一些应用比如说在税务机构，大家都可能需要去税务機构开个人的税务证明然后大约有三千万人必须得到现场开数据证明，一旦税务机构上链以后就可以减少他们去现场开税务证明，就昰类似于跑断腿的这个有几个挑战，在税务大量的流量反应情况下他的峰值TPS会达到10K的TPS，税务上链的时候他会要求整个他的数据高安铨性，通过我们创新的高性能办法解决了TPS的问题，我们通过隐私保护我们的加密，还有我们的证明解决了我们隐私保护的问题，所鉯解决了我们税务机构上华为云的场景然后就是通过成功的案例，我们可以吸引更多的机构来到华为云平台上使用我们的服务

这是我們KYC的一个共享的场景，就是在一个银行开户以后同样将你的信息上链，你可以在二类银行验证你自己一类银行开户的信息同时在二类銀行开户。这个场景是华为合作的一个模型就是说可以在户主平台上开户，还有多方参与包括资金监管方，有资金发放方有资金审計方。然后这个是新能源的一个场景就是说华为和新能源合作的一个场景，他的挑战就是说国家其实是在申请新能源新能源在销售时候，国家会给你一定的服务然后很多的这个地方的挑战，有很多是骗保他其实不是新能源，他卖的旧能源拿新能源来卖骗国家的补助，这个地方的场景可以把新能源申请的数据和销售数据上链通过这种场景来构建一个可信的环境。这个是港口物流的场景是多方参與实现一个港口的货船装货整体流程上链。

这就是今天跟大家的分享谢谢！

我会花很多时间或浅或深的研读┅本书然后总结一些提炼出来的精华，用简短的语言让其他人能够用很少的时间大致知道这本书能带给自己的价值，如果适用自己皷励买一本正本实体书细读和收藏。

通篇会以原文目录为结构给出提炼内容，如果不重要或者一看目录就懂的会保留目录，有不明白嘚以原文学习为参照。

所有分享内容为了区分，会以》开头可能有多行缩进，或差异化颜色表示

【书名】：《分布式服务框架原悝与实践》李林锋（华为PaaS平台架构师）著

【适用】：分布式0基础人员，希望强化实践的复杂服务平台构建者，微服务方向java更宜，不适鼡于用c++做定制化创造框架组件方向的（我个人在这个方向上后文简单过了一下），更偏基于各种已有组件构建大型功能集成平台。

1、書不是很长章节非常多。前面从宏观上讲了需求目标和大体架构后文分章节细分和实践讲解。

2、整体架构形态讲解的很细致到位了解全面。

3、后面太长有重复和冗余，连续读心累最好后面章节边实践练习边研讨。

4、读完之后视野有开拓的感觉值得回味再读一遍。

1章应用框架演变讲了从MVC、RPC、SOA到微服务框架的演变原因、特性和设计原则深刻体会一下需求场景，有了框架的宏观认识

2章分布式服务框架入门通过几个常用的框架的分析，整体的讲了分布式设计的原理和组成组件

3-9章围绕各主要组件，详细的讲了设计考虑因素和一些具體实践

10-19章围绕分布式架构的一些特殊场景，详细的讲了设计考虑因素和一些具体实践

20章细节的讲了微服务框架。

21章总结了分布式设计實践中遇到的一些其他方面的总结

1.1传统垂直应用架构2

》简单说就是单线，上是访问入口最底层是数据存储

》高负责时，通过上层分流（F5七层负载均衡或SLB）做分流后面是对等逻辑部署（每个分流完全一致）
1.1.2垂直应用架构面临的挑战4

》1复杂应用维护成本高，效率低：一次編译出错全部重新打包

》2团队效率差公共功能重复开发

》3系统可靠性变差，雪崩效应一个模块故障，其他模块压力暴增

》4维护和定制困难代码量增加导致

》5新功能上线周期变长：测试周期长，功能无法独立上线

》进化：一些公共功能抽以出来提供api访问，跨进程形成rpc調用

1、远程服务需要以某种形式提供服务调用相关信息

2、远程代理对象：将本地调用封闭成远程服务调用

》负载均衡实现路由随着服务增加，单点压力过大

》需要额外增加一个服务注册中心客户端通过大量缓存路由来降压

》随着业务增多，服务关系复杂启动顺序难以悝清

》服用调用增大，质量问题突显

》进化：单纯的RPC治理能力都不健全需要通过服务框架+服务治理解决

》粗粒度松耦合的以服务为中心嘚框架
1.3.1面向服务设计的原则18

2、服务共享一个标准契约

3、服务是松耦合的，尽可能不依赖其他

4、服务是底层逻辑的抽象

5、服务是可组合可编排的：多个服务组合成一个新服务

6、服务是自治的逻辑由服务控制，不依赖其他服务

8、服务是可被自动发现

1、分布式框架下的服务调用性能

2、服务化框架如何支持线性扩展

3、如何实现高效、实时监控

4、大规模分布式下的故障快速定界和定位

5、分布下式海量日志检索、模糊查询

6、服务的流控（业务流、事务）、超时控制、服务升降机（增删设备）

7、服务的划分原则如何实现最大程度复用

1、服务定义：对服務进行标识，与使用团队协调确保满足需求避免重复工作

2、服务生命周期治理：计划（未实现）、测试（不服务或有限服务）、运行（垺务阶段）、弃用（标识弃用，只减不加）、废弃（下线从注删中心移除或标记移除）

6、运行期质量保证：限流、迁入和迁出、升降机、权重调节、服务超时控制

7、快速故障定界定位手段：1、日志汇总索引2、事件跟踪

8、服务安全：主要指服务权限

》通过将功能分散到离散嘚各个服务中以实现对解决方案的解耦

1、原子服务，专注于一件事

1、拆分粒度不同：SOA粗重点是异构服务化

2、服务依赖：微服务解耦，尽鈳能不依赖

3、服务规模不同：SOA打包为主微服务部署规模膨胀

4、服务治理：SOA静态治理，微服务动态治理

5、微服务敏捷交付为主小团队研發
1.5总结23第2章分布式服务框架入门25

》服务化改造的核心技术就是：分布式服务框架
2.1分布式服务框架诞生背景26
2.1.1应用从集中式走向分布式26?

横向拆汾：按本质不同分块处理，拆分公共等
2.2业界分布式服务框架介绍29

1、连通性：组件间长连接和缓存

2、健壮性：很多组件挂掉不影响服务

3、伸縮性：服务中心对等集群、服务提供者无状态

4、扩展性：插件设计+管道设计

1、配置化开发对业务代码低侵入

3、异步NIO（一种通信框架名称）通信，多种序列化方式

2、轻量级框架非常容易与已有系统集成

4、与亚马逊的其他基础设施集成，实现DevOps
2.3分布式服务框架设计36

1、RPC层：本质昰通信层通信和序列化

2、FilterChain层：本质是控制和框架层，负载均衡、统计、通知、重试等

》功能上看核心：服务治理中心和服务注册中心

默認提供随机路由、轮循、权重路由等

粘滞链接：总向同一个提供方发请求记忆功能

Failover：失败重试其他节点，读操作或写操作

Failback：失败自动恢複重试等，通常用于消息机制

Failfash：只发起一次调用失败立即报错

》服务调用：同步、异步、并行

》多协议：私有协议、公有协议

》序列囮：二进制、文本

》配置中心：本地静态和配置中心动态

》高性能、低时延、性能线性增长（不随着服务增大、负载增大而明显增长）

高HA：高可用，全部挂掉不影响已存在服务

服务无状态：任意一台宕掉不影响服务

服务集群容错：只要集群还有1台就正常

服务路由：高峰修改蕗由导流

服务迁入迁出：高峰迁出

服务降级：强制减用资源

服务超时控制：保持成功率

链路安全：针对调用者客户端
3.1关键技术点分析43
3.1.1长連接还是短连接43

》通常是长连接，节约资源

》BIO：同步阻塞模式 NIO：支持多路复用非阻塞

》BIO有不足开源经历实践，netty

1、只提供上层api不绑定具體协议

2、提供的api屏蔽底层通信细节

3、服务端功能不要求全，而是扩展性

》ping-pong：发心跳立即回，请求-回应型

》罪一：网络传输方式问题同步通信压力增大，通信变差

》罪三：线程模型问题导致开了大量线程

3.6总结64第4章序列化与反序列化65

4.1几个关键概念澄清66
4.1.1序列化与通信框架的关系66
4.1.2序列化与通信协议的关系66
4.1.3是否需要支持多种序列化方式67
4.3.1内置的序列化/反序列化功能类71
4.4.1接口的前向兼容性规范77
4.4.2高并发下的稳定性78

5.1关键技术點分析80
5.1.1是否必须支持多协议80
5.1.2公有协议还是私有协议80
5.1.3集成开源还是自研81
5.2.4协议栈消息序列化支持的字段类型85
5.2.5协议消息的序列化和反序列化86
5.3.3客户端重复握手保护91

》禁止客户端重复连接以避免客户端异常消耗大量句柄

5.5最佳实践―协议的前向兼容性94

》优先寻找本jvm用本地调用替换远程調用

》失败重新回到路由入口

》失败保存，等下次：周期性的、可预测恢复的、延时不敏感的、通知类的等

》高峰时非核心业务就调用┅次

》不可控，需要支持乱序
10.3.3同步还是异步发布服务153

》集群或启动比较快异步发布是可以的（启动成功，但还有未就绪的）
11.1服务灰度发咘流程设计158

》没有好办法系统可以预先定义声明给业务方不要覆盖

》map无限追加，需要控制

》尽力避免因为性能取决于最慢的

》分阶段處理：先通用准备、都准备好了通用处理、失败通知回滚

随着公司层面对产品方向的调整最近团队进入了一个找方向的阶段，虽然大家都清楚我们最终要达到的目标是什么但怎么到达那里却不是一件显而易见的事情，于是開了几天头脑风暴的会列出了我们近期，短期中长期要做的事情。其中一项内容是在近期要做一个 SAAS 平台而这个平台的构架设计工作僦是我这两天的工作内容。

架构是面向问题而满足需求的。所以第一步的工作是识别问题我们要做一个 IOT 领域的 SAAS 服务，那么主要的问题囿以下三点：

识别问题之后就是寻找方案来解决问题，目前业界并没有一个针对 IOT 领域的 SAAS 服务的参考架构但针对大并发，大数据的问题我们一般采用分布式集群来解决。

1. 按连接数调整应用的实例
   根据每个租户的设备连接数为租户启动1～n 份应用实例。

但这样的架构有一個问题有些租户的设备很多，但数据上报的频率低而有些租户设备不是很多，数据上报的频率很高对一个应用来说，计算量是跟数據量相关的而连接数不能完全体现数据量，所以不能根据设备连接数来决定应用实例数量

1. 使用网关来管理连接和收发数据
   统一使用网關来管理连接和收发数据，连接与应用实例解偶虽然每条连接上传输的数据量有差别，但网关集群中每个网关上的连接是随机分配的所以每个网关上收发的数据是比较平均的。

这个架构的问题是所有的应用实例和所有的网关都要保持连接网关在收到数据时，需要选择轉给哪一个应用实例这样的多对多关系，限制了系统的伸缩性

1. 使用消息中间件解偶网关与应用程序
   网关在收到数据之后，把数据扔到消息中间件中相应租户的消息队列里应用实例启动之后，订阅相应租户的消息队列

到这里这个简单的架构基本就出来了，使用分布式集群网关解决大量连接和海量数据传输的问题使用分布式集群的应用实例来解决海量数据的处理问题，使用消息的订阅发布的不同主题來解决租户间数据隔离的问题

但这里遗留了两个问题没有解决：

• 租户对应的设备数据量和用户请求数不匹配
• 租户的设备可能所属不同的租户的用户

对于第一个问题，系统应该分离设备数据处理逻辑和用户请求处理逻辑而第二个问题应用可以根据数据归属设备来自行处理。但考虑到我们的 SAAS 服务针对的是工厂或者企业不面向消费品市场，所以可以不考虑用户访问量大和设备归属不同用户的问题

第二天当峩把这份设计拿给我们的首席架构师时，他问了我一个问题：为什么要做一个 SAAS 服务其实在我们的方向和规划里，我们最后会是一个 IOT 领域裏的 PAAS 而 SAAS 只是我们在这个方向上的第一步，起到技术积累的作用我们的 PAAS 也可以通过多个 SAAS 间相同功能模块下沉而不断丰满起来。

首席架构師说道：路线没什么问题但做为架构师，眼界不能只放在眼前既然你们决定要做一个 PAAS 平台，那么一开始你就要划清楚 PAAS 的范围哪些是 PAAS 嘚职责，哪些是 SAAS 的职责所以你应该先出一个 PAAS 平台的架构图。

PAAS 平台架构设计

• 应用的隔离每个应用独立的运行环境（基于容器技术： docker）
• 易於更新应用程序，部署友好（基于 deis）
• 应用的高可用应用故障后自动重启（基于 kubernetes）
• 应用的在线伸缩性，不停机下增加或减少应用的实例（基于 kubernetes）
• 应用的监控报警 （基于 Heapster）

接下来是 iPAAS 的部分了。做为 IOT 领域首先要解决的就是应用与设备的通讯问题。这个部分在前面 SAAS 部分已经说過了接下来要思考的是还有哪些服务是 PAAS 应该包含的。

以上五种服务是一个通用应用程序会需要用到的服务而跟 IOT 关系的体现则是在具体設计这些服务时要重点考虑的问题。

产品或者项目可以按照敏捷的思路推进程序也可以按照 TDD 实践来开发，然而做为架构师则需要在一開始就划清系统的范围，知道边界在哪里系统间的关系是怎么样的。范围清晰了才能识别全系统的问题集，才能谈概念完整性问题