详谈HTTPS SSL/TLS协议原理

协议安全和加密越来越引起人们的重视和关注,今天就跟大家分享一点协议加密方面的知识。要说清楚 HTTPS 协议的实现原理,至少需要如下几个背景知识。大致了解几个基本术语(HTTPS、SSL、TLS)的含义大致了解 HTTP 和 TCP 的关系(尤其是 “短连接”...
继续阅读 »

协议安全和加密越来越引起人们的重视和关注,今天就跟大家分享一点协议加密方面的知识。要说清楚 HTTPS 协议的实现原理,至少需要如下几个背景知识。

  1. 大致了解几个基本术语(HTTPS、SSL、TLS)的含义

  2. 大致了解 HTTP 和 TCP 的关系(尤其是 “短连接”VS“长连接”)

  3. 大致了解加密算法的概念(尤其是 “对称加密与非对称加密” 的区别)

  4. 大致了解 CA 证书的用途考虑到很多技术菜鸟可能不了解上述背景,俺先用最简短的文字描述一下。如果你自认为不是菜鸟,请略过本章节,直接去看 “HTTPS 协议的需求”。

一、先澄清几个术语——HTTPS、SSL、TLS。

1. “HTTP” 是干嘛用滴?

首先,HTTP 是一个网络协议,是专门用来帮你传输 Web 内容滴。关于这个协议,就算你不了解,至少也听说过吧?比如你访问俺的博客的主页,浏览器地址栏会出现如下的网址http://www.xxx.com/

俺加了粗体的部分就是指 HTTP 协议。大部分网站都是通过 HTTP 协议来传输 Web 页面、以及 Web 页面上包含的各种东东(图片、CSS 样式、JS 脚本)。

2. “SSL/TLS” 是干嘛用滴?

SSL 是洋文 “Secure Sockets Layer” 的缩写,中文叫做 “安全套接层”。它是在上世纪 90 年代中期,由网景公司设计的。(顺便插一句,网景公司不光发明了 SSL,还发明了很多 Web 的基础设施——比如“CSS 样式表” 和“JS 脚本”) 为啥要发明 SSL 这个协议捏?因为原先互联网上使用的 HTTP 协议是明文的,存在很多缺点——比如传输内容会被偷窥(嗅探)和篡改。发明 SSL 协议,就是为了解决这些问题。

到了 1999 年,SSL 因为应用广泛,已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS(是 “Transport Layer Security” 的缩写),中文叫做“传输层安全协议”。

很多相关的文章都把这两者并列称呼(SSL/TLS),因为这两者可以视作同一个东西的不同阶段。

3. “HTTPS” 是啥意思?

解释完 HTTP 和 SSL/TLS,现在就可以来解释 HTTPS 啦。咱们通常所说的 HTTPS 协议,说白了就是 “HTTP 协议” 和“SSL/TLS 协议”的组合。你可以把 HTTPS 大致理解为——“HTTP over SSL”或“HTTP over TLS”(反正 SSL 和 TLS 差不多)。

二、再来说说 HTTP 协议的特点

作为背景知识介绍,还需要再稍微谈一下 HTTP 协议本身的特点。HTTP 本身有很多特点,考虑到篇幅有限,俺只谈那些和 HTTPS 相关的特点。

1. HTTP 的版本和历史

如今咱们用的 HTTP 协议,版本号是 1.1(也就是 HTTP 1.1)。这个 1.1 版本是 1995 年底开始起草的(技术文档是 RFC2068),并在 1999 年正式发布(技术文档是 RFC2616)。

在 1.1 之前,还有曾经出现过两个版本 “0.9 和 1.0”,其中的 HTTP 0.9 没有被广泛使用,而 HTTP 1.0 被广泛使用过。另外,2015年IETF 就要发布 HTTP 2.0 的标准了。

2. HTTP 和 TCP 之间的关系

简单地说,TCP 协议是 HTTP 协议的基石——HTTP 协议需要依靠 TCP 协议来传输数据。在网络分层模型中,TCP 被称为 “传输层协议”,而 HTTP 被称为 “应用层协议”。

有很多常见的应用层协议是以 TCP 为基础的,比如 “FTP、SMTP、POP、IMAP” 等。

TCP 被称为 “面向连接” 的传输层协议。关于它的具体细节,俺就不展开了(否则篇幅又失控了)。你只需知道:传输层主要有两个协议,分别是 TCP 和 UDP。TCP 比 UDP 更可靠。你可以把 TCP 协议想象成某个水管,发送端这头进水,接收端那头就出水。并且 TCP 协议能够确保,先发送的数据先到达(与之相反,UDP 不保证这点)。

3. HTTP 协议如何使用 TCP 连接?

HTTP 对 TCP 连接的使用,分为两种方式:俗称 “短连接” 和“长连接”(“长连接”又称 “持久连接”,洋文叫做“Keep-Alive” 或“Persistent Connection”) 假设有一个网页,里面包含好多图片,还包含好多外部的CSS 文件和 JS 文件。在 “短连接” 的模式下,浏览器会先发起一个 TCP 连接,拿到该网页的 HTML 源代码(拿到 HTML 之后,这个 TCP 连接就关闭了)。然后,浏览器开始分析这个网页的源码,知道这个页面包含很多外部资源(图片、CSS、JS)。

然后针对每一个外部资源,再分别发起一个个 TCP 连接,把这些文件获取到本地(同样的,每抓取一个外部资源后,相应的 TCP 就断开) 相反,如果是 “长连接” 的方式,浏览器也会先发起一个 TCP 连接去抓取页面。但是抓取页面之后,该 TCP 连接并不会立即关闭,而是暂时先保持着(所谓的“Keep-Alive”)。然后浏览器分析 HTML 源码之后,发现有很多外部资源,就用刚才那个 TCP 连接去抓取此页面的外部资源。

在 HTTP 1.0 版本,默认使用的是 “短连接”(那时候是 Web 诞生初期,网页相对简单,“短连接” 的问题不大);到了 1995 年底开始制定 HTTP 1.1 草案的时候,网页已经开始变得复杂(网页内的图片、脚本越来越多了)。这时候再用短连接的方式,效率太低下了(因为建立 TCP 连接是有 “时间成本” 和“CPU 成本”滴)。

所以,在 HTTP 1.1 中,默认采用的是 “Keep-Alive” 的方式。关于 “Keep-Alive” 的更多介绍,可以参见维基百科词条。

三、谈谈 “对称加密” 和“非对称加密”的概念

1. 啥是 “加密” 和“解密”?

通俗而言,你可以把 “加密” 和“解密”理解为某种互逆的数学运算。就好比 “加法和减法” 互为逆运算、“乘法和除法”互为逆运算。

“加密”的过程,就是把 “明文” 变成 “密文” 的过程;反之,“解密”的过程,就是把 “密文” 变为“明文”。在这两个过程中,都需要一个关键的东东——叫做“密钥”——来参与数学运算。

2. 啥是 “对称加密”?

所谓的 “对称加密技术”,意思就是说:“加密” 和“解密”使用相同的密钥。这个比较好理解。就好比你用 7zip 或 WinRAR 创建一个带密码(口令)的加密压缩包。当你下次要把这个压缩文件解开的时候,你需要输入同样的密码。在这个例子中,密码 / 口令就如同刚才说的“密钥”。

3. 啥是 “非对称加密”?

所谓的 “非对称加密技术”,意思就是说:“加密” 和“解密”使用不同的密钥。这玩意儿比较难理解,也比较难想到。当年 “非对称加密” 的发明,还被誉为 “密码学” 历史上的一次革命。

由于篇幅有限,对 “非对称加密” 这个话题,俺就不展开了。有空的话,再单独写一篇扫盲。

4. 各自有啥优缺点?

看完刚才的定义,很显然:(从功能角度而言)“非对称加密”能干的事情比 “对称加密” 要多。这是 “非对称加密” 的优点。但是 “非对称加密” 的实现,通常需要涉及到 “复杂数学问题”。所以,“非对称加密” 的性能通常要差很多(相对于 “对称加密” 而言)。这两者的优缺点,也影响到了 SSL 协议的设计。

四、HTTPS 协议的需求是啥?

花了好多口水,终于把背景知识说完了。下面正式进入正题。先来说说当初设计 HTTPS 是为了满足哪些需求?

很多介绍 HTTPS 的文章一上来就给你讲实现细节。个人觉得:这是不好的做法。早在 2009 年开博的时候,发过一篇<学习技术的三部曲:WHAT、HOW、WHY>,其中谈到 “WHY 型问题” 的重要性。一上来就给你讲协议细节,你充其量只能知道 WHAT 和 HOW,无法理解 WHY。

俺在前一个章节讲了“背景知识”,在这个章节讲了“需求”,这就有助于你理解:当初为什么要设计成这样?——这就是 WHY 型的问题。

兼容性

因为是先有 HTTP 再有 HTTPS。所以,HTTPS 的设计者肯定要考虑到对原有 HTTP 的兼容性。这里所说的兼容性包括很多方面。比如已有的 Web 应用要尽可能无缝地迁移到 HTTPS;比如对浏览器厂商而言,改动要尽可能小;基于 “兼容性” 方面的考虑,很容易得出如下几个结论:

  1. HTTPS 还是要基于 TCP 来传输(如果改为 UDP 作传输层,无论是 Web 服务端还是浏览器客户端,都要大改,动静太大了)。

  2. 单独使用一个新的协议,把 HTTP 协议包裹起来 (所谓的 “HTTP over SSL”,实际上是在原有的 HTTP 数据外面加了一层 SSL 的封装。HTTP 协议原有的 GET、POST 之类的机制,基本上原封不动)。打个比方: 如果原来的 HTTP 是塑料水管,容易被戳破;那么如今新设计的 HTTPS 就像是在原有的塑料水管之外,再包一层金属水管。一来,原有的塑料水管照样运行;二来,用金属加固了之后,不容易被戳破。

可扩展性

前面说了,HTTPS 相当于是 “HTTP over SSL”。如果 SSL 这个协议在 “可扩展性” 方面的设计足够牛逼,那么它除了能跟 HTTP 搭配,还能够跟其它的应用层协议搭配。岂不美哉?

现在看来,当初设计 SSL 的人确实比较牛。如今的 SSL/TLS 可以跟很多常用的应用层协议(比如: FTP、SMTP、POP、Telnet)搭配,来强化这些应用层协议的安全性。

接着刚才打的比方: 如果把 SSL/TLS 视作一根用来加固的金属管,它不仅可以用来加固输水的管道,还可以用来加固输煤气的管道。

保密性

HTTPS 需要做到足够好的保密性。说到保密性,首先要能够对抗嗅探(行话叫 Sniffer)。所谓的 “嗅探”,通俗而言就是监视你的网络传输流量。如果你使用明文的 HTTP 上网,那么监视者通过嗅探,就知道你在访问哪些网站的哪些页面。

嗅探是最低级的攻击手法。除了嗅探,HTTPS 还需要能对抗其它一些稍微高级的攻击手法——比如 “重放攻击”。

完整性

除了 “保密性”,还有一个同样重要的目标是“确保完整性”。关于“完整性” 这个概念,在之前的博文<扫盲文件完整性校验——关于散列值和数字签名>中大致提过。健忘的同学再去温习一下。在发明 HTTPS 之前,由于 HTTP 是明文的,不但容易被嗅探,还容易被篡改。

举个例子: 比如咱们天朝的网络运营商都比较流氓,经常有网友抱怨说访问某网站(本来是没有广告的),竟然会跳出很多广告。为啥会这样捏?因为你的网络流量需要经过 ISP 的线路才能到达公网。如果你使用的是明文的 HTTP,ISP 很容易就可以在你访问的页面中植入广告。所以,当初设计 HTTPS 的时候,还有一个需求是 “确保 HTTP 协议的内容不被篡改”。

真实性

在谈到 HTTPS 的需求时,“真实性”经常被忽略。其实 “真实性” 的重要程度不亚于前面的 “保密性” 和“完整性”。

举个例子: 你因为使用网银,需要访问该网银的 Web 站点。那么,你如何确保你访问的网站确实是你想访问的网站?(这话有点绕口令) 有些天真的同学会说:通过看网址里面的域名来确保。

为啥说这样的同学是 “天真的”?因为 DNS 系统本身是不可靠的(尤其是在设计 SSL 的那个年代,连DNSSEC 都还没发明)。由于DNS 的不可靠(存在“域名欺骗” 和“域名劫持”),你看到的网址里面的域名未必是真实滴!所以,HTTPS 协议必须有某种机制来确保 “真实性” 的需求。

性能

再来说最后一个需求——性能。引入 HTTPS 之后,不能导致性能变得太差。否则的话,谁还愿意用?为了确保性能,SSL的设计者至少要考虑如下几点:

  1. 如何选择加密算法(“对称”or“非对称”)?

  2. 如何兼顾 HTTP 采用的 “短连接”TCP 方式?SSL 是在1995 年之前开始设计的,那时候的 HTTP 版本还是 1.0,默认使用的是 “短连接” 的 TCP 方式——默认不启用 Keep-Alive)。


收起阅读 »

记录一次接入华为推送问题

IM
接入的时候所有配置都正确的,但是启动项目就是不行报错,报错的信息也简单Execution failed for task ':app:mergeDebugManifest'. > com.android.manifmerger.Manif...
继续阅读 »

接入的时候所有配置都正确的,但是启动项目就是不行报错,报错的信息也简单

Execution failed for task ':app:mergeDebugManifest'.
> com.android.manifmerger.ManifestMerger2$MergeFailureException: java.io.FileNotFoundException: D:\HuaLu\app\build\intermediates\merged_manifests\debug\AndroidManifest.xml

初看以为是清单文件合并除了问题,但是最终还是排除了。实在没办法打印详细日志查看错误,

是华为的插件agconnect找不到,但是检查配置是没有问题的,编译也不会报错。后面又去华为官方论坛咨询

最后发现是Android studio4.1的Gradle4.1插件版本和融云文档上的

com.huawei.agconnect:agcp:1.3.1.300 有冲突,

解决办法是com.huawei.agconnect:agcp:1.4.1.300 修改为这个版本即可




收起阅读 »

日志审计系统的基本原理与部署方式

日志审计系统简介什么是日志审计?综合日志审计平台,通过集中采集信息系统中的系统安全事件、用户访问记录、系统运行日志、系统运行状态等各类信息,经过规范化、过滤、归并和告警分析等处理后,以统一格式的日志形式进行集中存储和管理,结合丰富的日志统计汇总及关联分析功能,...
继续阅读 »

日志审计系统简介

什么是日志审计?

综合日志审计平台,通过集中采集信息系统中的系统安全事件、用户访问记录、系统运行日志、系统运行状态等各类信息,经过规范化、过滤、归并和告警分析等处理后,以统一格式的日志形式进行集中存储和管理,结合丰富的日志统计汇总及关联分析功能,实现对信息系统日志的全面审计。

通过日志审计系统,企业管理员随时了解整个IT系统的运行情况,及时发现系统异常事件;另一方面,通过事后分析和丰富的报表系统,管理员可以方便高效地对信息系统进行有针对性的安全审计。遇到特殊安全事件和系统故障,日志审计系统可以帮助管理员进行故障快速定位,并提供客观依据进行追查和恢复。[百度百科]

为什么需要日志审计平台?

  1. 日志审计的合规要求,由于网络安全法的颁布实施,由原先的不合规转变成了不合法。如果不对要求的相关日志不做留存6个月以上,一旦追查,将面临法律责任。

  2. 安全运营的挑战。随着网络设备的增多,以及服务器数量的增多,如果没有统一的综合日志审计平台,那么需要登录到每台设备上查看日志,不利于运维人员管理。而且众多设备会产生海量的日志,无法有效管理。多种设备形成信息孤岛,日志无法关联分析。通过统一的日志审计平台,将所有设备日志都收集到日志平台进行统一管理,统一分析。

日志审计的核心目标:

  • 多源数据归一化

  • 日志存储集中化

  • 关联分析自动化

  • 安全态势立体化

日志审计的主要功能

设计思路:

统一日志采集:
  • 对不同日志源 (主机系统、网络设备、安全设备、应用中间件、数据库等)所产生的日志进行收集,实现日志的集中管理和存储。支持解析任意格式、任意来源的日志,通过解析规则标准化。

  • 使用无代理的方式收集日志。

  • 支持代理方式的日志收集。

关联分析:
  • 预置多种事件关联规则。

  • 定位外部威胁、黑客攻击、内部违规操作,设备异常。

  • 简单灵活定义关联规则。

实时告警:
  • 通过邮件、短信、声音对发生的告警进行及时通知,并可通过接口调用自动运行程序或脚本。

  • 通过告警策略定义,对各类风险 和事件进行及时告警或预警,提升运维效率。

日志取证分析:
  • 深入分析原始日志事件,快速定位问题的根本原因。

  • 生成取证报表,例如攻击威胁报表、Windows/Linux系统审计报表以及合规性审计报表等。

监管合规:
  • 提供Windows审计、Linux审计、PCI、SOX、ISO27001等合规性报表。

  • 支持创建自定义合规性报表

日志审计系统产品功能结构:

图:日志审计系统产品功能结构

日志审计系统的主要工作原理是,通过日志采集器,各种设备将日志推送到日志审计平台,然后日志审计平台通过日志解析,日志过滤,日志聚合等进行关联分析,从而进行告警,统计报表,也可以进行资产管理,日志检索等。

日志的转发方式:

日志转发一般可以通过:Syslog转发,Kafka转发,http转发。

日志收集一般支持:Syslog、SNMP等日志协议。

日志审计系统常见模块:

  • 日志事件获取模块:安全事件监控系统是实时掌握全网的安全威胁状况的重要手段之一。通过事件监控模块监控各个网络设备、主机系统等日志信息,以及安全产品的安全事件报警信息等,及时发现正在和已经发生的安全事件,通过响应模块采取措施,保证网络和业务系统的安全、可靠运行。

  • 资产管理模块:资产管理实现对网络安全管理平台所管辖的设备和系统对象的管理。它将其所辖IP设备资产信息按其重要程度分类登记入库,并为其他安全管理模块提供信息接口。

  • 规则库模块:规则库已支持主流网络设备、主机系统、数据库系统等,而且还应涵盖已经部署的安全系统,包括防火墙系统、防病毒系统等。并提供新日志格式适配功能,支持从安全运营中心平台接收新日志解析映射规则配置。用户可以根据该适配功能,对新日志格式进行自行适配。

  • 统计报表功能:具备强大的统计功能,可快速生成多种专业化的报表并支持自定义图表的设定集展示。

  • 权限管理模块:超级管理员可根据用户角色分配平台查看、操作各模块的权限,用户可以访问而且只能访问自己被授权的资源

日志审计平台的部署方式

硬件产品部署方式:

一般日志审计系统采用旁路部署即可,只要到达全部设备网络可通即可。

支持单机部署和分布式部署。


收起阅读 »

站在变革的十字路口,智慧医院还存在哪些建设误区?

在我国医疗信息化发展不断加速的进程上,医院作为连接医患群体、提供医疗服务的前线,似乎也走到了转型升级的十字路口。日前,以“智慧赋能·助力健康中国”为主题的2021全国智慧医院建设大会在上海召开,众多医疗从业者、云服务商、高校学者等共同聚焦医疗卫生事业,围绕智慧...
继续阅读 »

在我国医疗信息化发展不断加速的进程上,医院作为连接医患群体、提供医疗服务的前线,似乎也走到了转型升级的十字路口。

日前,以“智慧赋能·助力健康中国”为主题的2021全国智慧医院建设大会在上海召开,众多医疗从业者、云服务商、高校学者等共同聚焦医疗卫生事业,围绕智慧医院的建设思路展开了讨论和探索。

其中,中软国际云智能业务集团以其携手华为打造的智慧医院标杆项目“广东省第二人民医院”为例,重点提出了“全场景智慧、全要素协同、全业务运营,打造全场景智能医院”的观点,为下一代智慧医院的发展提供了诸多实践经验和建设思路。

不难发现,聚焦此次会议,伴随着产业融合趋势的来临,越来越多的医院走上了智能化转型的道路,而同时也有更多的云服务商投身其中,为智慧医院建设提供一体化解决方案,共同推动医疗信息化改革。

那么,在这样的驱动下,我国智慧医院是否能迎来一个光明的未来呢?

1 传统医院,是否到了变革的十字路口?

未来如何,得先确定一下未来是否会来,是否存在足够的条件支持传统医院走上转型升级的道路。

当前,我国正处于智慧医院建设的第一阶段。随着疫情防控的常态化开展、十四五规划的逐步落实,聚焦智慧医疗改革必然成为未来社会发展的关键方向。

事实上,近两年来,我国也一直在政策层面对智慧医院建设施加正向推力。在2018年,国务院办公厅便印发了《关于促进“互联网+医疗健康”发展的意见》,明确指出到2020年,二级以上医院普遍提供分时段预约诊疗、智能导医分诊、候诊提醒、检验检查结果查询、诊间结算、移动支付等线上服务,积极发展“互联网+医疗健康”,引入优质医疗资源,提高医疗健康服务的可及性。

因此,有了明确的发展方向,伴随着AI、5G、云计算、大数据等前沿技术的快速发展和深化应用,“互联网+”也顺势迭代升级至“AI+”。更多新技术的底层支持,促使医疗信息化改革面向医院场景实现了更全面的智能化转型。

在广东省第二人民医院,中软国际云智能业务集团携手华为通过整合AI、云、大数据等前沿技术,打造并应用了医院智慧运营中心HOC大脑,使得院区内防疫、安防、消防等各环节实现了一屏精准化管理,突破了传统医院的管理模式。

而这样的实践,也使得智慧医疗的市场加速扩容。据中国电子学会统计的最新数据显示,到2021年医疗人工智能行业市场规模将会达到75.3亿元。那么,新需求的增长吸引着更多医疗从业者和云服务商涌向这个市场,商业化的驱动使得智慧医院的建设进入一个更加良性的发展阶段。

目前,中软国际云智能业务集团等云服务商正是在这样的发展下,积极参与到智慧医院的建设,通过技术和运营的方式和传统医院联合,共同推动医疗的信息化改革。

总的来说,在十四五规划的开局之年,智慧医院建设的各方面条件都有了相对比较成熟的基础,政策上的正向推力、技术上的应用落地和市场上的商业驱动等等,都促使着智慧医院必然会成为未来发展的大趋势。

2 智慧医院,还存在哪些建设误区?

趋势可以判断,而过程又该如何展开?智慧医院建设本身就是一个驳杂多元的系统,且不说传统医院体系交叠复杂,就智能化的建设而言也面临着多方协调、长期投入的难点。

在这个道路上,注定不会简单。在此,我们或许可以从三个关键词来思考一下,智慧医院发展还存在着哪些建设上的误区?

1.     底座:光想着“建高楼”,不可忽视了“打基础”。

很多时候,传统行业的智能化升级不能只是原地起高楼,光想着在传统模式上部署项目、落实技术是不行的,新旧结合意味着流程重塑,还必须得统筹全局,打好基础。

比如,如果只是在原来的各个节点部署新系统,是否可以建设好智慧医院?答案是不能的。对此,中软国际云智能业务集团选择了以HOC大脑+八大应用+数字平台为主的顶层设计,实现院区从门诊到住院、从诊疗到科研、从患者体验到医护效率的全智能化覆盖,赋能医院从粗放式向精细化转变。

同时,“打基础”还不只是顶层设计的问题,从长远目标来看,更是整个医疗系统的全方位转型落实。因此,中软国际云智能业务集团在打造智慧院区解决方案上,重点也将云、AI、5G、大数据等技术应用于医、教、研、管等各个领域,做好各方面的转型工作。

以“研”来说,医药研发是日常患者并不关注的领域,但确是推动医疗行业发展的基础。将新技术应用于基础领域,正是立足在医疗行业的全局发展,从最核心的环节做好技术赋能。也只有把基础打好了,才能保证智慧医院的“高楼”建设稳定而又高效,这便是“底座”的价值。

2.    场景:哪些群体才是智慧医院的服务对象?

医院是面向患者的服务场景,而智慧医院不然,其需要面向患者,也需要面向医护人员、医院管理者、医联体等多个主体。因此,明确哪些群体才是智慧医院的服务对象至关重要。

如果无法兼顾多个服务对象,智慧化升级终究是不完整的,智慧医院也就名不副实。这也是为什么中软国际云智能业务集团致力于打造“全场景智能医院”的初衷。

面向患者,需要打造全流程智能就医,优化就诊体验;面向医护,需要打造智能工作站,辅助贯穿诊疗全流程;面向医院管理者,需要打造全方位可视、可管、可控的服务能力,推动精细化管理,等等。中软国际云智能业务集团在打造全场景智能医院时,正是明确了这些服务对象,进而针对特定的群体开展系统部署,提供全面的智能化升级服务。

中软国际云智能业务集团执行总裁孙佳韡认为,“这段时期,人们更多是给数字经济未来的腾飞建设一条相互连接公路,只有“路”修通了,数字经济才有了基础,人们才会真正认识到其所带来的新机会。”

很显然,对于智慧医院建设而言,需要搭建的正是让每一个对象触达智慧医院的“公路”,只有每一个人脚下的“路”修通了,智慧医院的成果才能真正惠及到社会。

3.    生态:”单打独斗”已成过去式,协同的价值可以发挥几何?

总的来说,智慧医院建设一个既宽泛也很有纵深的工程,这也决定了其必然需要一个长期的投入和布局。因此,在智慧医院的建设历程上,仅是一个人的单打独斗很乏力,更多是基于生态联合,整合优势才能撑起医院系统全方位的智能化。

因此,中软国际云智能业务集团在打造全场景智能医院的过程,也携手华为强强联合推动医疗信息化改革。此次2021全国智慧医院建设大会的召开,也正是希望在经验交流中集思广益,让更多的从业者看到合作的希望,通过生态整合来推动智慧医院的落地。

思维导向驱动发展进程。中软国际云智能业务集团所构想的“全场景智能医院”既然要全面,就必然需要连同更多的生态伙伴,在专业分工下打造完整的医院智能系统。

事实上,伴随着传统产业的智能化改革,这样生态路径会是常态,也是主流。这也意味着,智能化升级考验的不仅是自家的能力,也挑战者生态的水平,谁能携手更多更优质的生态伙伴,谁就拥有更大的市场优势。

3 下一代更智慧的医院,还有多远?

目前,我国智慧医院建设才刚刚起步,从三个关键词来看,建设者需要避免进入“基础不牢”、“服务对象不清晰”、“个人单打独斗”的误区。而做好底座建设、场景布局和生态合作三个层面的工作,也意味着智慧医院并非一蹴而就。

但也并不是遥不可及。中软国际云智能业务集团携手华为广东省第二人民医院打造智慧院区项目已取得了不错的反馈。据官方数据显示,基于智慧化升级,院区安保成本下降15%,能耗成本下降10%,就医时间成本减少了0.5h。

可见,在稳步的建设推动下,智慧医院相较于传统医院,正在持续优化院区管理和就医体验。只要伴随着前沿技术的深化应用和流程设计的科学部署,智慧医院将会从更多的层面推动医院系统和诊疗服务实现更便捷、高效的发展。

而在这个过程,更多的建设者需要看到智慧医院发展的误区,能笃定智慧医院的未来,并从前沿技术、诊疗流程、管理领域、生态伙伴等多个层面切实推动医院转型升级,才能迎来一个更智慧的未来医院。


收起阅读 »

从“十四五”规划看去中心化云计算的崛起

云计算发展如火如荼,但这个“云计算”却实际上被默认为“中心化”云计算,即集中化、统一归属的远程集群计算。然而,一种“去中心化”云计算正在快速兴起,成为不可忽视的力量。在十四五规划纲要中,2025年我国的数字经济核心产业增加值占GDP比重要从7.8%提升至10%...
继续阅读 »

云计算发展如火如荼,但这个“云计算”却实际上被默认为“中心化”云计算,即集中化、统一归属的远程集群计算。然而,一种“去中心化”云计算正在快速兴起,成为不可忽视的力量。

在十四五规划纲要中,2025年我国的数字经济核心产业增加值占GDP比重要从7.8%提升至10%,这其中,云计算、区块链等技术毫无疑问是建设数字中国的重要技术载体,在推动政企数字化变革、激发数字化技术与商业模式创新等方面有关键的作用。

区块链底层技术+云计算模式形成的“去中心化云计算”在产业政策导向下,大量玩家纷纷入局,以期在这个新领域占据先机、成为另一种形式的云计算巨头。

这包括想要成为“永不宕机的阿里云”的AELF区块链项目,号称要对标谷歌云、微软云的DADI区块链项目,以及自称“全球首家泛载雾计算平台”的博纳云(BonusCloud)、定位自己为“全球首个去中心化的云计算市场”的Akash(主要为DeFi提供去中心化云服务,即DeCloud)等。

而其中,有不少项目或企业已经进入实质性的应用阶段,取得了不错的市场成绩。例如宣称要做“去中心化云计算一站式服务领军者”的安迈云,其产品和解决方案在很多企业中得到落地应用。

以去中心化技术重构信任与安全,重塑传统集中式云计算的业务模型和资源分配结构,去中心化云计算正在推动数字经济更好、更快速地实现。

1 数字经济被提到新的高度,倒逼去中心化云计算快速发展?

一边是数字经济被列入未来宏观发展规划,另外一边,在数字经济推进过程中,很多挑战也逐渐显露出来,尤其是作为存储与计算发展主要力量的云计算,在应用到政企数字化转型过程中,出现很多亟待优化和解决的问题。在十四五规划的单列篇章五中,就对云计算发展有专门的论述,包括加快云操作系统迭代升级,推动超大规模分布式存储、弹性计算、数据虚拟隔离等技术创新,提高云安全水平等。

从这个意义上看,去中心化云计算的发展,首先通过帮助政企更好地实现数字化转型,契合了数字经济进一步发展的特征,从而实现了快速发展,这某种程度上是需求倒逼的结果。

1、成本:既要关注当下业务需求,更需要关注扩展需要

政企数字化越是往深处走,中心化云计算在成本方面的挑战就是凸显:如果说云计算相对于本地部署在成本上有巨大优势,那么当政企数字化走向深入后,复杂计算、大规模计算、海量数据存储等将同样给企业带来越来越沉重的负担。

较为典型的,如工业互联网建设,企业不得不为此在云计算上投入巨大的存储和计算成本。

而去中心化云计算由于采用的是分布式、不需要大批量基础设施建设的存储和计算节点,在成本上有巨大的优势,那些存储和计算规模庞大、任务繁重的企业,采用去中心化云计算将直接节约成本。

更进一步来看,由于去中心化的技术特性(个体节点、充分细分),当企业想要将存储和计算规模扩大(这是常态)时,在边际成本上也将变得更低。

如此,在门槛更低的情况下,政企组织接入云计算变得更容易,数字经济的规划落地也就扫除了参与度的障碍。

2、安全:既需要总体运行的安全,更需要个体数据的安全

云计算,或者说中心化云计算似乎生来就带有安全方面的挑战。

一方面,由于存储、计算的集中化,大量政企组织依赖一个平台,当中心化的平台出现运行问题,就会殃及几乎所有被服务方——中心化云计算的规模做得越大,这种运行方面安全问题的隐忧就越大。那些大型云计算平台的宕机事件每每都能成为业界“大新闻”,100%地把自己的身家性命压在了第三方服务器上的企业很难承受这样的宕机事故,但事故又层出不穷,受限于中心化的机制难以在根本上避免。

这时候,去中心化云计算的优势显露出现,分散的节点使得去中心化云计算理论上可以做到永不宕机,这是一种机制上的先天优势。

另一方面,在数据的归属上,客户与中心化云计算平台之间存在微妙的关系,上传的文件、处理业务的数据沉淀如何保证隐私性和安全性是政企客户常常考虑的问题,很多时候数据安全的保障甚至只能靠中心化平台的“自觉”,这显然不符合数字经济时代的需要。

3、体验:既需要灵活多样的弹性服务,更需要定制化的专业服务

尽管传统中心化云计算一直在进行弹性存储和计算方面的技术更新,但这种弹性往往只是尽可能拟合现实需要,企业实际应用时,在需要变动十分复杂时,还是会不可避免地出现配置资源不足或浪费的情况。

这是由于传统中心化云计算一般都是先有订单再有服务,资源的配置需要系统的划分,弹性调整需要极为复杂的技术来实现,往往无法做到真正的“要多少、给多少、收多少费用”。

而去中心化云计算由于节点被最大程度分散,在低颗粒度的情况下,弹性服务的提供上更有潜力。

此外,数字化转型走向深入后,很多政企组织对定制化服务的需求越来越显著,契合自身需要的产品和解决方案变得更重要,但在中心化情况下,这可能是属于大客户才能享有的待遇。

在去中心化云计算这里,情况或能够得到改善,例如,安迈云构建的去中心化云计算产品体系中,类似IPFS基础设施解决方案这种服务,能够很好地利用去中心化的高可用性、资源独享、部署灵活等特征,为客户定制优化的分布式存储的解决方案。

总得看来,在宏观政策导向下,“传统”中心化云计算与“政策期望”之间的差距,正在被去中心化云计算所弥合。

2 区块链价值落地,给去中心化云计算带来新的价值想象空间?

不可忽视的是,去中心化云计算本质可以算是区块链技术的一个重要应用,从区块链的角度看,它则是中国乃至全球区块链产业蓬勃发展的代表,成为业界所期待的有效落地项目之一。

而正是从这个角度,而不是单纯从云计算角度看,去中心化云计算又可以为数字经济带来新的价值想象空间。

1、数字资产流转新蓝海,需要新的基础设施

数据隐私的保护其实背后暗含另一层意义,即数据资产的归属与处置问题。隐私得到很好的保护,会使得用户将数据的价值控制在自己手中,从而催生商业模式创新。

在区块链技术的加持下,去中心化云计算中的数据,有机会完成中心化云计算难以完成的数据资产确权等工作,用户在链上可以便捷、安全地向第三方有偿分享数据信息,从而让自己的数据池变成某种数字资产,换取收益。

在这种情况下,国家大力倡导的数字经济,在数据底层原料层面将变得更加有活力。

2、多样性计算各有所长,计算与硬件匹配才能大大提升效率

云计算的底层架构,在传统的X86之外,近年来ARM等架构的计算芯片崛起,且厂商众多。在分布式云计算中,由于参与成为节点的硬件各异,使得用户总能够根据自身的需要,在链上找到对应的、能够最大程度发挥芯片架构优势加速运行效率的计算硬件,使得计算找到最好的硬件匹配。

换言之,用户不但可以快速进行横向的计算能力扩展,也更容易找到效果更好、成本控制更优的多样化计算硬件。

而对比来看,很多中心化云计算平台还在为了多样性计算的兼容而投入大量资源。

3、特殊数字场景凸显“既要……又要……”难题,亟待解决

随着数字经济走向全领域、全场景,很多过去被认为是云计算“禁区”的特殊数字场景,也不得不顺应时代需求进行变革升级,金融场景最为典型。

出于监管的需要,过去在金融领域,数据必须放在本地,很难进行远程外部机房的连接访问工作,这影响了计算效率的发挥,让银行等核心金融机构在数字化这件事上似乎总是慢半步。

现在,去中心化云计算借助安全、保密难以被攻破的区块链技术,能最大程度保证金融数据安全,同时扩展更多存储与计算服务。

类似的场景还有更多,这些最难的堡垒打下来后,数字经济才能真正实现落地。

3 搭上趋势快车,但去中心化云计算“颠覆”却不“替代”?

毫无疑问,与传统的云计算相比,去中心化云计算是一种模式上的颠覆,是区块链技术的重要落地应用,最大程度契合了宏观政策对云计算推动数字经济发展的期盼。

但是,必须看到的是,同样在政策导向下,去中心化云计算却并不对传统中心化云计算形成替代,只是在补足后者无法很好地满足的领域,共同服务于数字经济时代。所以,中心化与去中心化云计算的并存将成为一种常态,有业内人士认为,二者将凭借各自优势分享市场(例如,中心化云计算在社交、电商这类实时、复杂、高频应用中有天然优势),各占50%的份额。

甚至,去中心化云计算中的IPFS作为一个面向全球的、点对点的分布式版本文件系统,其有不少节点使用的是微软、谷歌、阿里云等公司的云服务器(这并不违背去中心化原则,中心化的平台所提供的存储和计算服务只作为一个节点存在),这种特殊的关系证明了二者的共存将是未来的常态。

当去中心化云计算平台逐步发展起来,可以发现,它们并不是搅局者,而是为云计算多走出一条路、创造“另一个未来”。但无论如何,这个市场都足够广阔,新的巨头料将出现,在经历缓慢发展后(IPFS去中心化的核心组件开发已经8年之久),去中心化云计算的爆发可能即将来临。


收起阅读 »

浅谈Token多平台身份认证架构设计思路

1、概述在存在账号体系的信息系统中,对身份的鉴定是非常重要的事情。随着移动互联网时代到来,客户端的类型越来越多, 逐渐出现了 一个服务器,N个客户端的格局 。不同的客户端产生了不同的用户使用场景,这些场景:有不同的环境安全威胁不同的会话生存周期不同的用户权限控...
继续阅读 »
1、概述

在存在账号体系的信息系统中,对身份的鉴定是非常重要的事情。

随着移动互联网时代到来,客户端的类型越来越多, 逐渐出现了 一个服务器,N个客户端的格局 。

不同的客户端产生了不同的用户使用场景,这些场景:

  • 有不同的环境安全威胁

  • 不同的会话生存周期

  • 不同的用户权限控制体系

  • 不同级别的接口调用方式

综上所述,它们的身份认证方式也存在一定的区别。

本文将使用一定的篇幅对这些场景进行一些分析和梳理工作。

2、使用场景

下面是一些在IT服务常见的一些使用场景:

  • 用户在web浏览器端登录系统,使用系统服务

  • 用户在手机端(Android/iOS)登录系统,使用系统服务

  • 用户使用开放接口登录系统,调用系统服务

  • 用户在PC处理登录状态时通过手机扫码授权手机登录(使用得比较少)

  • 用户在手机处理登录状态进通过手机扫码授权PC进行登录(比较常见)

通过对场景的细分,得到如下不同的认证token类别:

1、原始账号密码类别
  • 用户名和密码

  • API应用ID/KEY

2、会话ID类别
  • 浏览器端token

  • 移动端token

  • API应用token

3、接口调用类别
  • 接口访问token

  • 身份授权类别

  • PC和移动端相互授权的token

3、token的类别

不同场景的token进行如下几个维度的对比:

天然属性对比:
1、使用成本

本认证方式在使用的时候,造成的不便性。比如:

  • 账号密码需要用户打开页面然后逐个键入

  • 二维码需要用户掏出手机进行扫码操作

2、变化成本

本认证方式,token发生变化时,用户需要做出的相应更改的成本:

  • 用户名和密码发生变化时,用户需要额外记忆和重新键入新密码

  • API应用ID/KEY发生变化时,第三方应用需要重新在代码中修改并部署

  • 授权二维码发生变化时,需要用户重新打开手机应用进行扫码

环境风险

  • 被偷窥的风险

  • 被抓包的风险

  • 被伪造的风险

可调控属性对比:

1、使用频率

在网路中传送的频率

2、有效时间

此token从创建到终结的生存时间

最终的目标:安全和影响。

安全和隐私性主要体现在:

  • token 不容易被窃取和盗用(通过对传送频率控制)

  • token 即使被窃取,产生的影响也是可控的(通过对有效时间控制)

关于隐私及隐私破坏后的后果,有如下的基本结论:

  • 曝光频率高的容易被截获

  • 生存周期长的在被截获后产生的影响更严重和深远

遵守如下原则:

  • 变化成本高的token不要轻易变化

  • 不轻易变化的token要减少曝光频率(网络传输次数)

  • 曝光频率高的token的生存周期要尽量短

将各类token的固有特点及可控属性进行调控后, 对每个指标进行量化评分(1~5分),我们可以得到如下的对比表:

备注:user_name/passwd 和 app_id/app_key 是等价的效果

4、token的层级关系

参考上一节的对比表,可以很容易对这些不同用途的token进行分层,主要可以分为4层:

  • 密码层:最传统的用户和系统之间约定的数字身份认证方式

  • 会话层:用户登录后的会话生命周期的会话认证

  • 调用层:用户在会话期间对应用程序接口的调用认证

  • 应用层:用户获取了接口访问调用权限后的一些场景或者身份认证应用

token的分层图如下:

在一个多客户端的信息系统里面,这些token的产生及应用的内在联系如下:

  • 用户输入用户名和用户口令进行一次性认证

  • 在 不同 的终端里面生成拥有 不同 生命周期的会话token

  • 客户端会话token从服务端交换生命周期短但曝光 频繁 的接口访问token

  • 会话token可以生成和刷新延长 access_token 的生存时间

  • access_token可以生成生存周期最短的用于授权的二维码的token

使用如上的架构有如下的好处:

  • 良好的统一性。可以解决不同平台上认证token的生存周期的 归一化 问题

  • 良好的解耦性。核心接口调用服务器的认证 access_token 可以完成独立的实现和部署

  • 良好的层次性。不同平台的可以有完全不同的用户权限控制系统,这个控制可以在 会话层 中各平台解决掉

4.1、账号密码

广义的 账号/密码 有如下的呈现方式:

  • 传统的注册用户名和密码

  • 应用程序的app_id/app_key

它们的特点如下:

1、会有特别的意义

比如:用户自己为了方便记忆,会设置有一定含义的账号和密码。

2、不常修改

账号密码对用户有特别含义,一般没有特殊情况不会愿意修改。而app_id/app_key则会写在应用程序中,修改会意味着重新发布上线的成本

3、一旦泄露影响深远

正因为不常修改,只要泄露了基本相当于用户的网络身份被泄露,而且只要没被察觉这种身份盗用就会一直存在

所以在认证系统中应该尽量减少传输的机会,避免泄露。

4.2、客户端会话token

功能:

充当着session的角色,不同的客户端有不同的生命周期。

使用步骤:

用户使用账号密码,换取会话token

不同的平台的token有不同的特点:

Web平台生存周期短

主要原因:

  • 环境安全性:由于web登录环境一般很可能是公共环境,被他人盗取的风险值较大

  • 输入便捷性:在PC上使用键盘输入会比较便捷

移动端生存周期长

主要原因:

  • 环境安全性:移动端平台是个人用户极其私密的平台,它人接触的机会不大

  • 输入便捷性:在移动端上使用手指在小屏幕上触摸输入体验差,输入成本高

4.3、access_token

功能:

服务端应用程序api接口访问和调用的凭证。

使用步骤:

使用具有较长生命周期的会话token来换取此接口访问token。

其曝光频率直接和接口调用频率有关,属于高频使用的凭证。为了照顾到隐私性,尽量减少其生命周期,即使被截取了,也不至于产生严重的后果。

注意:在客户端token之下还加上一个access_token, 主要是为了让具有不同生命周期的客户端token最后在调用api的时候, 能够具有统一的认证方式。

4.4、pam_token

功能:

由已经登录和认证的PC端生成的二维码的原始串号(Pc Auth Mobile)。

主要步骤如下:

  1. PC上用户已经完成认证,登录了系统

  2. PC端生成一组和此用户相关联的pam_token

  3. PC端将此pam_token的使用链接生成二维码

  4. 移动端扫码后,请求服务器,并和用户信息关联

  5. 移动端获取refresh_token(长时效的会话)

  6. 根据 refresh_token 获取 access_token

  7. 完成正常的接口调用工作

备注:

  • 生存周期为2分钟,2分钟后过期删除

  • 没有被使用时,每1分钟变一次

  • 被使用后,立刻删除掉

  • 此种认证模式一般不会被使用到

4.5、map_token

功能:

由已经登录的移动app来扫码认证PC端系统,并完成PC端系统的登录(Mobile Auth Pc)。

主要步骤:

  1. 移动端完成用户身份的认证登录app

  2. 未登录的PC生成匿名的 map_token

  3. 移动端扫码后在db中生成 map_token 和用户关联(完成签名)

  4. db同时针对此用户生成 web_token

  5. PC端一直以 map_token 为参数查找此命名用户的 web_token

  6. PC端根据 web_token 去获取 access_token

  7. 后续正常的调用接口调用工作

备注:

  • 生存周期为2分钟,2分钟后过期删除

  • 没有被使用时,每1分钟变一次

  • 被使用后,立刻删除掉

5、小结与展望

本文所设计的基于token的身份认证系统,主要解决了如下的问题:

  • token的分类问题

  • token的隐私性参数设置问题

  • token的使用场景问题

  • 不同生命周期的token分层转化关系

本文中提到的设计方法,在 应用层 中可以适用于且不限于如下场景中:

  • 用户登录

  • 有时效的优惠券发放

  • 有时效的邀请码发放

  • 有时效的二维码授权

  • 具有时效 手机/邮件 验证码

  • 多个不同平台调用同一套API接口

  • 多个平台使用同一个身份认证中心

至于更多的使用场景,就需要大家去发掘了。

*来源于公众号-程序猿DD

收起阅读 »

什么是充血模型?什么又是贫血模型?

贫血模型即事务脚本模式充血模型即领域模型模式贫血模型最早广泛应用源于EJB2,最强盛时期则是由Spring创造,把“行为”(逻辑、过程)“状态”(数据,对应到语言就是对象成员变量)分离到不同的对象中:只有状态的对象就是所谓的“贫血对象”(常称为VO——Valu...
继续阅读 »
  • 贫血模型即事务脚本模式

  • 充血模型即领域模型模式

贫血模型

最早广泛应用源于EJB2,最强盛时期则是由Spring创造,把

  • “行为”(逻辑、过程)

  • “状态”(数据,对应到语言就是对象成员变量)

分离到不同的对象中:

  • 只有状态的对象就是所谓的“贫血对象”(常称为VO——Value Object)

  • 只有行为的对象就是我们常见的N层结构中的Logic/Service/Manager层(对应到EJB2中的Stateless Session Bean)。(曾经Spring的作者Rod Johnson也承认,Spring不过是在沿袭EJB2时代的“事务脚本”,也就是面向过程编程)

贫血领域模型是一个存在已久的反模式,目前仍有许多拥趸者。Martin Fowler曾经和Eric Evans聊天谈到它时,都觉得这个模型似乎越来越流行了。作为领域模型的推广者,他们觉得这不是一件好事。

贫血领域模型的基本特征是:它第一眼看起来还真像这么回事儿。项目中有许多对象,它们的命名都是根据领域来的。对象之间有着丰富的连接方式,和真正的领域模型非常相似。但当你检视这些对象的行为时,会发现它们基本上没有任何行为,仅仅是一堆getter/setter。其实这些对象在设计之初就被定义为只能包含数据,不能加入领域逻辑。这些逻辑要全部写入一组叫Service的对象中。这些Service构建在领域模型之上,使用这些模型来传递数据。

这种反模式的恐怖之处在于,它完全和面向对象设计背道而驰。面向对象设计主张将数据和行为绑定在一起,而贫血领域模型则更像是一种面向过程设计,Martin Fowler和Eric在Smalltalk时就极力反对这种做法。更糟糕的时,很多人认为这些贫血领域对象是真正的对象,从而彻底误解了面向对象设计的涵义。

如今,面向对象的概念已经传播得很广泛了,而要反对这种贫血领域模型的做法,还需要更多论据。贫血领域模型的根本问题在于,它引入了领域模型设计的所有成本,却没有带来任何好处。最主要的成本是将对象映射到数据库中,从而产生了一个O/R(对象关系)映射层。只有当你充分使用了面向对象设计来组织复杂的业务逻辑后,这一成本才能够被抵消。如果将所有行为都写入到Service对象,那最终你会得到一组事务处理脚本,从而错过了领域模型带来的好处。正如martin在企业应用架构模式一书中说到的,领域模型并不一定是最好的工具。

将行为放入领域模型,这点和分层设计(领域层、持久化层、展现层等)并不冲突。因为领域模型中放入的是和领域相关的逻辑——验证、计算、业务规则等。如果你要讨论能否将数据源或展现逻辑放入到领域模型中,这就不在本文论述范围之内了。

一些面向对象专家的观点有时会让人产生疑惑,他们认为的确应该有一个面向过程的服务层。但是,这并不意味着领域模型就不应该包含行为。事实上,service层需要和一组富含行为的领域模型结合使用。

Eric Evans的Domain Driven Design一书中提到:

  • 应用层(即Service层)

描述应用程序所要做的工作,并调度丰富的领域模型来完成它。这个层次的任务是描述业务逻辑,或和其它项目的应用层做交互。这层很薄,不包含任何业务规则或知识,仅用于调度和派发任务给下一层的领域模型。这层没有业务状态,但可以为用户或程序提供任务状态。

  • 领域层(或者叫模型层)

表示业务逻辑、业务场景和规则。该层次会控制和使用业务状态,即使这些状态最终会交由持久化层来存储。总之,该层是软件核心。

服务层很薄——所有重要的业务逻辑都写在领域层。他在服务模式中复述了这一观点:如今人们常犯的错误是不愿花时间将业务逻辑放到合适的领域模型中,从而逐渐形成面向过程的程序设计。

我不清楚为什么这种反模式会那么常见。我怀疑是因为大多数人并没有使用过一个设计良好的领域模型,特别是那些以数据为中心的开发人员。此外,有些技术也会推动这种反模式,比如J2EE的Entity Bean,这会让我更倾向于使用POJO领域模型。

总之,如果你将大部分行为都放置在服务层,那么你就会失去领域模型带来的好处。如果你将所有行为都放在服务层,那你就无可救药了。

优点

简单

  • 对于只有少量业务逻辑的应用来说,使用起来非常自然

  • 开发迅速,易于理解

  • 注意:也不能完全排斥这种方式

缺点

无法良好的应对复杂逻辑

  • 比如收入确认规则发生变化,例如在4月1号之前签订的合同要使用某规则…..

  • 和欧洲签订的合同使用另外一个规则…..

充血模型

面向对象设计的本质:“一个对象是拥有状态和行为的”,比如一个人:

  • 他眼睛什么样鼻子什么样这就是状态

  • 人可以去打游戏或是写程序,这就是行为

为什么要有一个“人Manager”这样的东西存在去帮人“打游戏”呢?举个简单的J2EE案例,设计一个与用户(User)相关功能。传统的设计一般是:

  • 类:User+UserManager

  • 保存用户调用:userManager.save(User user)

充血的设计则可能会是:

  • 类:User

  • 保存用户调用:user.save()

  • User有一个行为是:保存它自己

其实它们没有什么特别适用的方向,个人更倾向于总是使用充血模型,因为OOP总是比面向过程编程要有更丰富的语义、更合理的组织、更强的可维护性—当然也更难掌握。因此实际工程场景中,是否使用,如何使用还依赖于设计者以及团队充血模型设计的理解和把握,因为现在绝大多数J2EE开发者都受贫血模型影响非常深。另外,实际工程场景中使用充血模型还会碰到很多很多细节问题,其中最大的难关就是“如何设计充血模型”或者说“如何从复杂的业务中分离出恰到好处且包含语义的逻辑放到VO的行为中”。

如果一个对象包含其他对象,那就将职责继续委托下去,由具体的 POJO 执行业务逻辑,将策略模式更加细粒度,而不是写 ifelse。


收起阅读 »

分页场景(limit, offset)为什么会慢?

从一个问题说起五年前发现分页场景下,mysql请求速度非常慢。数据量只有10w的情况下,select xx from 单机大概2,3秒。我就问我导师为什么,他反问“索引场景,mysql中获得第n大的数,时间复杂度是多少?”答案的追寻确认场景假设status上面...
继续阅读 »
从一个问题说起

五年前发现分页场景下,mysql请求速度非常慢。数据量只有10w的情况下,select xx from 单机大概2,3秒。我就问我导师为什么,他反问“索引场景,mysql中获得第n大的数,时间复杂度是多少?”

答案的追寻
确认场景

假设status上面有索引。select * from table where status = xx limit 10 offset 10000。会非常慢。数据量不大的情况就有几秒延迟。

小白作答

瞎猜了个log(N),心想找一个节点不就是log(N)。自然而然,导师让我自己去研究。

这一阶段,用了10分钟。

继续解答

仔细分析一下,会发现通过索引去找很别扭。因为你不知道前100个数在左子树和右子数的分布情况,所以其是无法利用二叉树的查找特性。通过学习,了解到mysql的索引是b+树。

看了这个图,就豁然开朗了。可以直接通过叶子节点组成的链表,以o(n)的复杂度找到第100大的树。但是即使是o(n),也不至于慢得令人发指,是否还有原因。

这一阶段,主要是通过网上查资料,断断续续用了10天。

系统学习

这里推荐两本书,一本《MySQL技术内幕 InnoDB存储引擎》,通过他可以对InnoDB的实现机制,如mvcc,索引实现,文件存储会有更深理解。

第二本是《高性能MySQL》,这本书从着手使用层面,但讲得比较深入,而且提到了很多设计的思路。

两本书相结合,反复领会,mysql就勉强能登堂入室了。

这里有两个关键概念:

  • 聚簇索引:包含主键索引和对应的实际数据,索引的叶子节点就是数据节点

  • 辅助索引:可以理解为二级节点,其叶子节点还是索引节点,包含了主键id。

即使前10000个会扔掉,mysql也会通过二级索引上的主键id,去聚簇索引上查一遍数据,这可是10000次随机io,自然慢成哈士奇。这里可能会提出疑问,为什么会有这种行为,这是和mysql的分层有关系,limit offset 只能作用于引擎层返回的结果集。换句话说,引擎层也很无辜,他并不知道这10000个是要扔掉的。以下是mysql分层示意图,可以看到,引擎层和server层,实际是分开的。

直到此时,大概明白了慢的原因。这一阶段,用了一年。

触类旁通

此时工作已经3年了,也开始看一些源码。在看完etcd之后,看了些tidb的源码。无论哪种数据库,其实一条语句的查询,是由逻辑算子组成。

逻辑算子介绍 在写具体的优化规则之前,先简单介绍查询计划里面的一些逻辑算子。

  • DataSource 这个就是数据源,也就是表,select * from t 里面的 t。

  • Selection 选择,例如 select xxx from t where xx = 5 里面的 where 过滤条件。

  • Projection 投影, select c from t 里面的取 c 列是投影操作。

  • Join 连接, select xx from t1, t2 where t1.c = t2.c 就是把 t1 t2 两个表做 Join。

选择,投影,连接(简称 SPJ) 是最基本的算子。其中 Join 有内连接,左外右外连接等多种连接方式。

select b from t1, t2 where t1.c = t2.c and t1.a > 5 变成逻辑查询计划之后,t1 t2 对应的 DataSource,负责将数据捞上来。上面接个 Join 算子,将两个表的结果按 t1.c = t2.c连接,再按 t1.a > 5 做一个 Selection 过滤,最后将 b 列投影。下图是未经优化的表示:

所以说不是mysql不想把limit, offset传递给引擎层,而是因为划分了逻辑算子,所以导致无法直到具体算子包含了多少符合条件的数据。

怎么解决

《高性能MySQL》提到了两种方案

方案一

根据业务实际需求,看能否替换为下一页,上一页的功能,特别在ios, android端,以前那种完全的分页是不常见的。这里是说,把limit, offset,替换为>辅助索引(即搜索条件)id的方式。该id再调用时,需要返回给前端。

方案二

正面刚。这里介绍一个概念:索引覆盖:当辅助索引查询的数据,只有id和辅助索引本身,那么就不必再去查聚簇索引。

思路如下:`select xxx,xxx from in (select id from table where second_index = xxx limit 10 offset 10000)“ 这句话是说,先从条件查询中,查找数据对应的数据库唯一id值,因为主键在辅助索引上就有,所以不用回归到聚簇索引的磁盘去拉取。再通过这些已经被limit出来的10个主键id,去查询聚簇索引。这样只会十次随机io。在业务确实需要用分页的情况下,使用该方案可以大幅度提高性能。通常能满足性能要求。


收起阅读 »

听说过OpenJDK,没说过OpenValueJDK吧?

你听说过OpenJDK,但是你听说过OpenValueJDK吗?近日一家来自欧洲、从事Java生态的全栈软件公司OpenValue准备干一件大事。他们受到一个叫Bluebonnet[1]的开源项目的启发(一个在.NET平台部分实现的JVM),打算开发一个新的 ...
继续阅读 »

你听说过OpenJDK,但是你听说过OpenValueJDK吗?近日一家来自欧洲、从事Java生态的全栈软件公司OpenValue准备干一件大事。他们受到一个叫Bluebonnet[1]的开源项目的启发(一个在.NET平台部分实现的JVM),打算开发一个新的 JDK,这个 JDK 将同时支持 Java 和.NET 字节码!这就是OpenValueJDK。说干就干,目前OpenValueJDK 官方网站[2]已经放出来了,但是更多的细节还没放出来。

OpenValueJDK

OpenValue放言他们计划于明年 4 月 1 日发布第一版。现在大公司都在玩跨语言的全栈JVM,Oracle 刚刚推出了 GraalVM,现在又来一个OpenValueJDK,JVM生态越来越热闹了。

Java 和 .NET 曾经是水火不容的两套生态系统,它们都可以用于构建软件、网站和 Web 应用程序。Java程序员和.NET程序员曾经因为谁更好争的“死去活来”。

但是由于Java可以可以运行在任何一种操作系统之上,经过 25 的发展已经构建了一个无可比拟的生态体系。而.NET则走了和Java相反的路子,虽然微软也开始认识到开源和跨平台的重要性,但是为时已晚,.NET生态和Java生态已经不可同日而语。

我很期待明年 4 月 1 日的OpenValueJDK,嗯 4 月 1 日发布!


收起阅读 »

继Elastic怒喷云服务商白嫖之后,AWS 终于退出ES的开源分支:OpenSearch!

一直关注DD的朋友应该还记得,今年年初时Elastic公司曾宣布改变其名下的开源协议,而对此AWS(Amazon Web Services——Amazon云服务)就随即表示自己将在仍为开源状态的 Elasticsearch 和 Kibana( 7.10 版本)...
继续阅读 »

一直关注DD的朋友应该还记得,今年年初时Elastic公司曾宣布改变其名下的开源协议,而对此AWS(Amazon Web Services——Amazon云服务)就随即表示自己将在仍为开源状态的 Elasticsearch 和 Kibana( 7.10 版本)创建分支,今后自己来维护这个分支,做到真正的开源。

转眼间已经过了快三个月,当初的这个真正的开源事件就在近日有了下文。

4月12号,AWS官方宣布推出 OpenSearch 项目!

根据AWS的官方介绍,OpenSearch 项目由OpenSearch和OpenSearch Dashboards组成,这两项的确也都是基于当初所说的Elasticsearch 和 Kibana( 7.10.2 版本)。

项目均采用Apache License 2.0 开源许可协议,功能完成度也不少,包括像企业安全、告警、机器学习、SQL、索引状态管理等,应有尽有。

而针对Elasticsearch之前的改变以及自己的真开源讲法,AWS表示OpenSearch虽然时基于Elasticsearch,但是删除了其中和Elastic有关的商业许可证限制、代码、商标等,在采用了Apache License 2.0 之后,OpenSearch可以让每个用户都毫无负担的构建和创新,而不用再担心一些贡献之外的问题。

同时,AWS还宣布现有的 Amazon Elasticsearch Service,将会变更名号,成为一个崭新的Amazon OpenSearch Service!

更名之后的Amazon OpenSearch Service,想必是为了摆脱和Elasticsearch的关联,在不影响正在运营业务的前提下,还会提供一系列可供部署和运行的开源引擎,包括当前可用的 19 个版本的 Elasticsearch(7.9 和更早版本、近期推出的 7.10)以及新版本的 OpenSearch。

为了满足现有用户的使用需要,AWS还宣布未来的Amazon OpenSearch Service API 将与现有服务 API 完美兼容,还会为用户提供将现有 Elasticsearch 6.x 和 7.x 托管集群迁移至 OpenSearch 的无缝升级路径。

可能在未来的几周内,我们就能见到AWS发布 Beta 版本,根据AWS的展望,预计在2021年中期发布稳定版并投入生产环境使用。

随着AWS的声明,不少公司都纷纷站队表示支持,像红帽、SAP、Capital One 和 Logz.io 都是其坚定的盟友。

红帽表示:

我们感谢亚马逊对开放搜索的承诺,我们很高兴看到亚马逊继续支持开源

SAP表示:

SAP客户期望一个统一的、以业务为中心的、开放的SAP业务技术平台。OpenSearch提供了一个真正的开源途径和社区驱动的方法来推动这一进程。

Capital One说到:

我们非常支持OpenSearch项目,因为它将使我们能够更好地控制和自主选择数据平台,同时保留开放源代码许可证提供的自由。

而第一个站出来吐槽Elastic公司的Logz.io则发言:

我们承诺与AWS和社区其他成员合作,创新并使世界各地的每个组织都能享受这些关键的开源项目带来的好处。

那到底AWS的OpenSearch能不能达到大家的预期呢?我们拭目以待!


收起阅读 »