精华内容
下载资源
问答
  • 本文将对CNAPP的发展演进脉络进行分析。 二、传统主机保护平台 01 终端保护平台 云原生应用程序保护平台最初起源于终端保护平台(Endpoint Protection Platform,EPP)。虽然一些企业现在仍在使用EPP产品作为保护...

    文作者:安全内参社区研究员 安未然

     

    一、前言

    云计算、大数据和人工智能的来临,上云已经成为组织数字化转型的必由之路。云原生作为云计算的下一个阶段,相关的开发和部署模式已经成为业界趋势,技术、产品、标准和解决方案的生态系统也在同步扩张之中,决策者面临着跟进这些复杂设计的挑战。

    云原生技术应用产生了新的云安全需求,CISO 要在竞争激烈的云原生市场中确保业务安全。传统的防火墙、反病毒、服务器监控、终端检测响应和SIEM等安全产品,与云原生的适配性较好,容易部署上云。但工作负载安全、威胁检测、用户行为监控、合规与风险管理等安全产品,无法适应云原生技术的新安全需求,需要进行专门的重新设计。

    过去的几年,诞生了云工作负载保护平台CWPP(Cloud Workload Protection Platform)、云安全态势管理CSPM(Cloud Security Posture Management)等云安全产品,对云原生安全的保护发挥了重要作用。但是,随着新应用场景的出现、技术的演化和市场的变化趋势,云原生应用保护平台(Cloud-Native Application Protection Platform, CNAPP)的概念诞生,渐有统一CWPP和CSPM之势。本文将对CNAPP的发展演进脉络进行分析。

     

    二、传统主机保护平台

     

    01 终端保护平台

    云原生应用程序保护平台最初起源于终端保护平台(Endpoint Protection Platform,EPP)。虽然一些企业现在仍在使用EPP产品作为保护服务器工作负载的安全产品,但是EPP是面向物理终端设备(台式机、笔记本电脑和平板电脑等)的解决方案,不适合企业混合云场景下的工作负载保护的要求。

    在这种场景下,基础架构是由本地服务器、虚拟服务器以及公有云环境共同组成,主要的保护目标是服务器的工作负载。EPP产品的继续使用会使企业的数据和应用程序处在巨大的安全风险之中。传统的以数据中心、网络和终端为主要保护对象的安全理念和产品,需要向混合云场景进行演进。

     

    02 混合云场景下的云工作负载保护平台

    混合云的部署架构逐渐被市场接受。为了满足混合云场景下的工作负载保护,云工作负载保护平台(Cloud Workload Protection Platform, CWPP)随之产生。CWPP最初(2016年)基于主机安全的解决方案进行定义,区别于EPP的PC维度,CWPP主要解决的问题在于数据中心维度。CWPP强调了混合数据中心架构需要统一的管理、Linux系统的重点支持、杀毒软件的无效、定价灵活性以及跟云平台的对接和API与DevSecOps的结合等等。

    从技术角度来看,最核心的是跟云平台原生的对接,利用AWS或者Azure提供的接口来进行相关安全措施的处理。比如说通过VPC接口可以做到相关业务的微隔离,也可以通过网络流量日志来进行流量的安全分析。

    2017年,CWPP增加了外部场景的云工作负载安全服务(WAF、Firewall和IPS等),进一步增强云工作负载的保护。并且,开始采用控制面的安全措施(IAM配置、网络配置以及管理员访问等)。

    此外,容器的出现,使得用户无法对线上系统进行处理,安全措施需要前移到开发环节,并且运行时的应用控制和容器的锁定需要作为新的防御手段,云工作负载保护架构随之发生了变化。新架构要求对SDL流程的支持,与自动化CI/CD工具的结合,要求API可以灵活调用,将安全检查前移。

     

    03 混合多云场景下的云工作负载保护平台

    2018年,大部分组织开始在使用至少两个厂商的云计算服务。混合多云的部署架构成为市场的主流。为了满足混合多云场景下云工作负载保护,CWPP需要提供统一的安全策略管理,以减少企业的知识鸿沟。

    同时,CWPP的管理需要自动化,从而更好地与DevSecOps相结合。例如,在自动化生成工作负载时,自动化安装和配置相关的软件或安全策略。

    此外,CWPP开始注重机器学习技术对产品能力金字塔各个层面的加强作用。例如,对于微隔离层面,机器学习可以先学习和观察正常的情况,然后建立白名单,随着时间的推移不断更新和修正策略以达到不用人工介入就可设置安全策略的状态。

    然而,CWPP并不能解决Serverless计算方式所带来的安全问题,势必需要对工作负载的定义进行重新和全面审视。因而,Gartner在2019年对工作负载的外延和内涵进行细粒度解释,根据抽象度的不同分为物理机、虚拟机、容器和Serverless。

    这几种工作负载从虚拟化水平到单位的计量再到生命周期都有很大的区别。能力金字塔因而发生了重大变化。从原来的11个能力删减到8个能力,并且将最底层的“运维习惯”与“加固、配置与漏洞管理”进行了整合。删掉了“欺骗防御”能力,因为欺骗/蜜罐系统是单独产品提供。同时数据的静态加密大部分情况下都有云厂商提供,比如AWS的EBS加密和Azure的磁盘加密,因此“静态加密IaaS数据”这个能力也从能力金字塔中删掉了。但是加强了对威胁检测和响应的要求,相当于要学习EDR的能力。

    图片

    图1:工作负载抽象

     

    2020年,CWPP能力金字塔进一步精简,文件加密和防病毒从其中移除。目前的能力,从最核心的开始,按照重要性逐渐递减的排序,包括八层:加固、配置和漏洞管理,基于身份的隔离和网络可视化,系统完整性保证,应用控制/白名单,预防漏洞利用和内存管理,服务器工作负载行为监测、威胁检测和响应,主机防入侵和漏洞屏蔽,扫描恶意软件。

     

    图片

    图2:基于风险的工作负载保护控制层次结构

     

     

    三、云原生应用保护平台

     

    01 云原生应用保护平台的产生背景

    首先,从安全市场角度来看,云原生技术持续深入发展和广泛普及势必带来新的网络安全发展机遇,产生庞大的网络安全需求,并推动云安全业务向纵深发展。

    其次,从安全生态角度来看,安全产品的融合发展成为必然选择。CWPP在数据面对云工作负载进行保护,CSPM在控制面对云工作负载进行保护。

    值得注意的是,当前大多数的云安全事件都是配置错误和管控失当引起的,凸显正确配置和合规的重要性,控制面的安全变得越加重要。数据面和控制面的云安全产品通过相互融合组成统一的解决方案,能够更好地保护多云和多租户,云原生应用保护平台(CNAPP)由此产生。

    最后,从云安全实际需求角度来看,混合多云仍将是组织和机构未来一段时期的基础架构

     

    但是,工作负载的粒度、生命周期以及创建方式发生了显著变化,云安全保护需求势必也会发生变化。

    首先,组织正在越来越多地采用容器和Serverless等技术进行云原生应用开发,工作负载的粒度越来越来越细,云原生安全保护需要适应工作负载粒度的变化。

    其次,容器和Serverless等形式的云原生开发的流行,工作负载的生命周期越来越短,部署在这些工作负载上的恶意软件也呈现出快速变化的特点。传统的基于签名文件加载或反恶意软件扫描的方式无法及时响应,基于行为建模的方案也因无法收集足够案例变得失效。云原生安全保护需要适应工作负载的生命周期越来越短的变化。

    最后,工作负载越来越通过镜像构建和替换,正在向不变的基础设施转变。云原生安全保护同样需要适应这种变化。

     

    02 云原生应用程序保护平台的主要特点

    总的来说,CNAPP将会吸收CWPP和CSPM的能力,不仅需要把不同的安全解决方案集成在一起,跨越不同技术边界实施一致的安全策略,提供统一的云原生保护,还需要采用面向安全的架构设计(例如,零信任),识别动态工作负载中的属性和元数据,自动化地保护开发、发布、部署和运营等整个生命周期。

    首先,CNAPP无疑仍将聚焦动态混合、异构多云架构场景下的工作负载保护,重点是跨不同技术边界实施一致的安全策略。

    其次,CNAPP需要具备对所有粒度的工作负载进行保护的能力。云原生应用需要虚拟机、容器和无服务器PaaS组合起来提供服务,单一的工作负载保护无法保证应用的整体安全。并且,随着工作负载的粒度和动态变化,CNAPP策略和产品也许必须动态适应、弹性伸缩。

    第三,CNAPP需要对开发、发布、部署和运营等整个生命周期进行保护。现在的CWPP主要关注工作负载运营阶段的保护,缺乏对其他阶段的保护。CNAPP需要注重基于基础设施的不变性进行保护。在开发阶段,使用安全测试来识别合规和配置的相关问题,为持续改进提供快速、可操作的反馈流程。在发布阶段,持续地对工作负载镜像(例如容器镜像)进行自动扫描和更新,避免遭受漏洞、恶意软件、危险代码以及其它不当行为的侵害,确保所依赖的开源软件和第三方应用等软件供应链的安全。在部署时,对工作负载镜像的属性进行的验证(例如,签名、安全策略等)。

    第四,CNAPP需要适应云原生开发的快速迭代,基于CI/CD 实现自动化。云原生追求的本质目标是效率,CI/CD作为效率提升的重要手段,是云原生的关键特性。云原生时代,不满足CI/CD自动化的安全产品,将摧毁云原生的价值,也就不能算作云原生安全保护。

    第五,CNAPP需要重点加强配置保护和合规性检查能力云计算基础设施错误配置带来的安全风险要比攻破工作负载带来的安全风险更大。CSPM能够对云计算技术设施的配置和合规性进行持续评估和改进,CNAPP需要充分吸收CSPM的这种能力。        

    第六,CNAPP需具备对云原生应用程序进行威胁检测和响应的能力CWPP主要依赖于预防性控制,而CNAPP需要采用CARTA战略框架和自适应安全架构,对云原生应用程序以及相关工作负载的行为进行监控。

     

    参考资料:

    [1]CWPP产品市场演进.安全内参.https://www.secrss.com/articles/9984

    [2]CASB、CSPM、CWPP三大云安全工具应用场景详解 .安全内参. https://www.secrss.com/articles/15597

    [3]Gartner 2020年十大安全项目详解 .安全内参. https://www.secrss.com/articles/26342

    [4]云原生带来的云安全机遇.安全内参.https://www.secrss.com/articles/23726

     

     

    本文来源:安全内参

     

    图片

    努力打造“有特色、高水平、国际化”的网络安全思想高地。

     

    图片

    展开全文
  • 区块链,元宇宙的“开门之匙”  仅仅只是简单地将元宇宙与区块链划等号,其中一个很直接的结果就是将会混淆两者...换句话说,区块链的技术进步直接关系到元宇宙的未来发展演进。如果元宇宙之后,还有“第二宇宙”、

      区块链,元宇宙的“开门之匙”
      仅仅只是简单地将元宇宙与区块链划等号其中一个很直接的结果就是将会混淆两者之间的主次地位当越来越多的人将元宇宙与区块链深度联系他们仅仅只是看到了元宇宙被资本市场和行业巨头们追捧的现实并未真正明了区块链与元宇宙之间的内在联系在很多情况下,区块链扮演的是元宇宙的“开门之匙”的角色和作用。
      所谓的“开门之匙”主要体现的是区块链的技术演进对于其他外在的技术之间的推进作用换句话说区块链的技术进步直接关系到元宇宙的未来发展演进如果元宇宙之后,还有“第二宇宙”“第三宇宙”的话,那么真正导致这些新的物种出现的底层技术一定是区块链技术本身的演进与进化。
      首先,大数据、云计算人工智能、3D、VR/AR等新技术是不断演进的只有不断演进,才能够让他们与现实的商业之间建构起新的关系这是我们现在看到新技术与现实商业之间结合并且不断衍生出新的物种的关键原因所以,我们通常情况下所说的新技术并不仅仅只是固定不变而是不断进化。
      其次,对于区块链来讲若想要真正把新技术串联在一起形成一个商业闭环仅仅只是借助那些尚未改变的技术模式是不够的,依然还需要不断演进从这个角度来看我们还需要不断对区块链技术进行演进和进化只有这样,区块链才能跟得上其他新技术演进的步伐从而继续发挥它的聚合和融通的功能和作用。
      通过以上分析我们可以非常明显地看出,区块链是打开元宇宙大门的钥匙每一个新事物本身,必然需要新的区块链技术作为注脚与推进器,如果仅仅只是简单地看到的区块链在开启元宇宙之门的作用,却忽略了区块链在元宇宙演进过程当中的所发挥的功能和作用,那么,所谓的元宇宙,必然仅仅只是一个停滞的存在,无法与最新的技术联系在一起。而当元宇宙没有了新技术作为的给养,那么,它的发展同样将会失去发展动能,最终甚至还有可能会枯萎。
      从这个角度来看,我们所说的区块链与元宇宙之间的天然联系,仅仅只是某个阶段的元宇宙与区块链之间的联系。只有不断地推动区块链的技术进步,不断让区块链继续扮演新技术的聚合器的功能和作用,元宇宙本身才能够不断演进和进化。
      当元宇宙逐渐风靡,我们看到的是越来越多的人开始将它与区块链深度绑定,甚至还有人说区块链就是元宇宙。如果仅仅只是将区块链与元宇宙之间的关系局限于此,如果仅仅只是以此来定义区块链与元宇宙之间的联系,那么,所谓的元宇宙必然会陷入到新的死胡同里。理顺元宇宙与区块链之间的关系,并且真正找到元宇宙的正确发展之道,才是保证元宇宙可以持续发展的关键所在。
     

    展开全文
  • 业务模式演进1.1 发展历程1.1.1 萌芽期(96-99)1.1.2 发展期(00-10)1.1.3 稳定期(11-今)1.2 业务模式1.2.1 B2C1.2.2 C2C1.2.3 B2B1.2.4 O2O1.2.5 其他1.3 电商中台1.3.1 背景1.3.2 概述1.3.3 业务中台1.3.4 ...

    1. 业务模式演进

    1.1 发展历程

    1.1.1 萌芽期(96-99)

    96年:国家信息化领导小组成立
    97年4月:各省成立信息化小组
    97年12月:中国化工网B2B上线
    98年3月:第一笔互联网交易完成 (个人第一笔交易经历?)
    98年11月:腾讯成立
    99年5月:8848网成立
    99年8月:易趣网
    99年9月:阿里巴巴
    99年11月:当当网
    

    1.1.2 发展期(00-10)

    00年4月:慧聪网B2B
    00年5月:卓越网(现:亚马逊中国)开启B2C模式
    00年6月:中国电子商务协会成立
    01年:13所高校开启电子商务专业
    01年11月:8848暂停电子商务
    02年3月:eBay收购易趣33%的股份
    02年10月:阿里实现收支平衡
    03年5月:淘宝网成立,C2C
    03年6月:eBay全盘收购易趣C2C
    03年10月:阿里推出支付宝
    03年12月:慧聪网香港上市
    04年1月:京东涉足电子商务
    04年8月:亚马逊收购卓越
    05年9月:腾讯推出拍拍网(拍拍网的使用经历?)
    06年5月:淘宝推出淘宝商城
    07年11月:阿里巴巴登陆香港证券市场
    08年:经济危机部分严重依赖外贸的电商倒闭
    09年6月:当当宣布首季盈利
    10年1月:苏宁易购上线
    10年11月:国美电器控股库巴购物网进军电子商务
    

    1.1.3 稳定期(11-今)

    12年1月:淘宝商城改为天猫
    12年3月:唯品会上市
    19年:天猫双11交易额2684亿
    11年至今:天猫、京东、苏宁、国美、各大电商趋于稳定
    

    1.2 业务模式

    电商早期多以单体业务为主,逐个业务线扩张。系统也多呈现为多个mvc独立运行状态。下面逐个介绍
    各个单体的业务模式,以及他们各自的系统运行特点。

    1.2.1 B2C

    1)简介
    	Business to Consumer(Customer),B2C中的B是Business,意思是企业,2则是to的谐音,C是
    	Customer,意思是消费者,所以B2C是企业对消费者的电子商务模式。这种形式的电子商务一般以网
    络零售业为主,主要借助于Internet开展在线销售活动。
    2)系统特点
    	因为面向大量消费者,网站访问量较大,对网站并发行有一定要求,但交易方式相对简单。
    3)案例
    	天猫商城
    	京东
    	苏宁易购
    	国美电器
    

    1.2.2 C2C

    1)简介
    Consumer to Consumer,意思是个人与个人之间的电子商务。 C2C 商务平台就是通过为买卖双方提
    供一个在线交易平台,使卖方可以主动提供商品上网拍卖,而买方可以自行选择商品进行竞价。比如一
    个消费者有一台电脑,通过网络进行交易,把它出售给另外一个消费者。
    2)系统特点
    同B2C一样,网站访问量是重点。
    3)案例
    闲鱼
    58交易
    

    1.2.3 B2B

    1)简介
    	Business to Business,即企业与企业之间通过互联网进行产品、服务及信息的交换。通俗的说法是指
    	进行电子商务交易的供需双方都是商家(或企业、公司)。一般来讲,过程包括:发布供求信息(现
    	货,期货),订货及确认订货(议价,集采,聚投),支付(先货后款,先款后货,分期支付),票据
    	的签发、传送和接收(验货,验票),确定配送方案(物流),监控配送过程(违约与仲裁)等。
    2)系统特点
    	与C端用户不同,B端访问量相对小,但是交易周期的流程,以及交易的监督相对复杂。
    3)案例
    	中国化工
    	阿里巴巴
    	慧聪网
    	中国供销电子商务
    	中粮我买网
    

    1.2.4 O2O

    1)简介
    	Online to Offline,O2O 是新兴起的一种电子商务新商业模式,即将线下商务的机会与互联网结合在了
    	一起,让互联网成为线下交易的工具。这样线下服务就可以用线上来引流,消费者可以用线上来筛选服
    	务,还有成交可以在线结算,高效完成部分线下的前期环节。
    2)系统特点
    	O2O整合了线上购买+线下体验的模式,多为服务性商品,比如餐饮,娱乐等。尤其是移动互联网的接
    	入,对O2O系统就有针对用户做定制化服务的要求,比如位置定位、周边服务、定向推送等。
    3)案例
    	各类团购
    	外卖网
    	打车类
    	共享单车
    

    1.2.5 其他

    1)ABC
    Agent、Business、Consumer。ABC 模式是新型电子商务模式的一种,被誉为继阿里巴巴 B2B 模式、
    京东商城 B2C 模式以及淘宝 C2C 模式之后电子商务界的第四大模式。它由代理商、商家和消费者共同
    搭建的集生产、经营、消费为一体的电子商务平台。
    2)B2M
    Business to Manager。B2M 相对于 B2B、B2C、C2C 有着本质的不同,其根本的区别在于目标客户群
    的性质不同,前三者的目标客户群都是作为一种消费者的身份出现,而 B2M 所针对的客户群是该企业
    或者该产品的销售者或者为其工作者,而不是最终消费者。
    3)M2C
    Manager to Consumer。M2C 是针对于 B2M 的电子商务模式而出现的延伸概念。B2M 环节中,企业
    通过网络平台发布该企业的产品或者服务,职业经理人通过网络获取该企业的产品或者服务信息,并且
    为该企业提供产品销售或者提供企业服务,企业通过经理人的服务达到销售产品或者获得服务的目的。
    4)B2A/B2G
    A:Administration,G:Government。是企业与政府管理部门之间的电子商务,如政府采购,海关报
    税的平台,国税局和地税局报税的平台等。
    5)C2A/C2G
    Consumer to Administration。 消费者对行政机构的电子商务,指的是政府对个人的电子商务活动。
    例如政府的税务机构通过指定私营税务,或财务会计事务所用电子方式来为个人报税。
    

    1.3 电商中台

    1.3.1 背景

    (供销电商的真实经历,背景,发展与问题?)
    1)技术架构的需要
    烟囱式系统建设:业务部门提出业务需求,信息中心部门进行系统集成,再进入到需求收集、需求分
    析、开发、测试、上线的项目周期中。每个新系统的上线都预示着一座新的烟囱矗立而成。这种完全基
    于业务需求建设系统的方式,已经成为过去20多年企业建设IT系统的标准流程,导致IT系统建设早的企
    业内部系统烟囱林立。
    造成的问题:
    重复功能建设和维护带来的重复投资
    系统间的集成和协作成本高昂
    不利于业务的沉淀和持续发展。
    2)组织架构的需要
    IT信息部门在现有模式下往往被定位成了一个服务部门。 这使得IT信息化部门一直处于『业务支持』的
    职能位置,即只为了满足业务部门需求而进行IT系统建设的实施和运维部门。这种模式下, 很多企业的
    IT信息化部门的员工大多数的工作内容都是开发上线开发上线。而对业务缺乏某一专业领域的经验和沉
    淀。基于中台下的共享业务技术部,使得核心公共业务沉淀,让IT部门与上层业务更贴近,能够对业务
    的下一步发展有着自己的理解和看法,对业务流程如何进一步优化能更好地提升业务,甚至对企业现有
    的业务提出创新的想法,为企业带来新的业务增长点。

    1.3.2 概述

    综合前面的业务模式,各个业务类型中,都具备基本的商品、交易、库存、支付等公共部分。提炼这部
    分基础内容,进行沉淀,逐步形成中台基础能力层,而个性化的业务流程部分上浮,形成产品层。这样
    做的好处是,基础能力层聚焦于稳定收敛的业务模型和基础服务本身,不会随着业务和前台产品的调整
    发生大的变化,平台产品层则专注于通过流程编排类的技术手段,将基础能力构建成业务的解决方案,
    解决共性和个性化的问题。即大中台,小前端。
    

    在这里插入图片描述

    1.3.3 业务中台

    	商品中心:商品、类目、sku、spu
    	交易中心:订单、状态流转、条目、支付
    	营销中心:促销、优惠券、活动
    	会员中心:账户、基本信息、收发货地址、商铺商家信息
    	仓储中心:仓库、库存
    	物流中心:发货信息、自主物流或外部物流对接
    

    1.3.4 技术中台

    基础架构:核心类库、公共框架、基础服务、服务治理框架
    中间件:分布式缓存、分布式消息、数据存储(db,nosql)、分布式文件、分布式调度
    自动化运维:监控中心、资源管理、配置中心、发布中心、日志平台
    自动化测试:任务协同、基础测试、性能测试、接口测试、持续集成
    (运维中台的争议?)
    

    1.3.5 数据中台

    数据抽取:从db,nosql,日志等各个来源提供抽取接口
    数据接口:为上层业务提供需要的定制化业务数据接口
    数据分析:行业分析与决策、数据驱动运营
    人工智能:用户画像、商品推荐
    可视化:数据大屏、信息展示、活动报表
    

    1.4 发展趋势

    1.4.1 移动电商

    移动电子商务(M-Commerce),它由电子商务(E-Commerce)的概念衍生出来,传统电子商务以
    PC机为主要界面,是“有线的电子商务”;而移动电子商务,则是通过智能手机、平板电脑这些可以装在
    口袋里的终端与我们谋面,无论何时、何地都可以开始。有人预言,移动商务将决定21世纪新企业的风
    貌,也将改变生活与旧商业的地形地貌。
    主要特点:随时随地、实时在线、精准推送营销
    面临挑战:终端的多样化
    

    1.4.2 社交电商

    电商说到底就是通过线上流量把货卖出去。社交电商顾名思义,与传统电商网站的区别在于流量的导入
    方式是借助社交圈。社交电商,一般通过点赞、分享、转发、自媒体推荐等通过自己的社会关系 去制造
    和产生流量。而传统电商是做平台,借助平台的力量去助推销售。
    传统电商以货为中心,围绕商品、供应链的传统卖货平台。
    社交电商以人为中心,是社交关系形成的电商形态,不以产品搜索、展示为销售模式,而是通过社交,
    用户分享传播,形成口碑效应,从而激发消费需求。
    拼多多历经短短2年3个月的时间就在美国纳斯达克正式上市,而这个成绩,淘宝用了10年,京东用了5
    年。
    案例:拼多多、有赞、微商、抖音、淘宝直播
    特点:容易形成圈子效应
    面临挑战:对口碑的要求很高、社交和交易的界限不好把控
    

    1.4.3 新零售

    新零售,英文是New Retailing,在2016年的10月,马云提出了新零售就是线上、线下、物流相结合。
    即个人、企业以互联网为依托,通过运用大数据、人工智能等先进技术手段,对商品的生产、流通与销
    售过程进行升级改造,进而重塑业态结构与生态圈,并对线上服务、线下体验以及现代物流进行深度融
    合的零售新模式。
    在线上零售的冲击下,传统的纯线下零售在历经了地产整合、渠道升级、品牌崛起等发展阶段后,很难
    有新突破。而线上零售也逐渐探到传统流量模式的天花板。于是线上、线下、技术、数据、供应链等场
    景都在寻求相互融合,形成线上交易结合线下体验店的新零售。
    案例:阿里巴巴全面布局"新零售"市场;京东主推"无界零售";苏宁则依靠"智慧零售" 迎来九年来最佳
    业绩
    

    2. 架构体系演进

    2.1 概述

    任何体系的成型不是一蹴而就,随着访问量,数据量的增长,业务需求在推动技术架构的发展变革。下
    面我们以淘宝的发展历程为例,来看系统架构的演进过程。
    1)架构目标
    	高性能:提供快速的访问体验,高并发下的及时响应。
    	高可用:网站服务7x24正常访问,可用性达到几个9。
    	可伸缩:资源的扩容,应对突发和流量脉冲。
    	安全性:提供网站安全访问和数据加密、安全存储等策略。
    	扩展性:方便对现有模块做版本升级,新模块的上线,突发活动下的服务降级。
    	敏捷性:对系统突发情况的快速排查与应对。
    2)演进概述
    	部署层面:单机到集群,集中式到分布式,物理部署到云化
    	业务层面:单一mvc到垂直拆分,服务治理到微服务
    	数据层面:db到集群,单一关系型数据到多样化nosql,搜索引擎,文件服务
    

    2.2 单机器时代

    小型网站,阿里云小项目还有人在用。
    1)方案
    	大型机:引发对单机性能的过度追求,推动高配机器的发展,成本高昂
    	调优:jvm单节点调优甚至接近于强迫症的地步
    2)特点
    	部署简单:采用web包部署与发布,db同台机器连接,简单易操作。
    	资源争夺:在业务发展的初始阶段尚可支撑,随着访问量的上升,单机性能很快会成为系统瓶颈。
    

    在这里插入图片描述

    2.3 数据分离

    稍微大一点的系统,dba出现,数据库追逐商业大型db如oracle,如(淘宝v1.1 , mysql→oracle)
    1)方案
    	多台机器:tomcat与mysql各自独占机器资源
    	针对性扩容:tomcat应用机更注重cpu的运算和内存,mysql更注重io与磁盘性能,针对各自情况扩容
    2)特点
    	数据维护:可以抽出单独的dba来维护数据库服务器
    	数据安全:需要跨机器访问数据库,链接密码需要注意防范泄漏
    	数据库瓶颈:数据库频繁读写,io很快成为瓶颈
    

    在这里插入图片描述

    2.4 数据缓存

    2006-2007,淘宝V2.2架构,分布式缓存Tair引入。(08-09创业初期memcache+ssh1时代的故事)
    

    在这里插入图片描述

    1)方案
    	数据冷热划分:热点数据如类目、商品基础信息热加载,其他数据延迟加载
    	ehcache:非分布式,简单,易维护,可用性一般
    	memcache:性能可靠,纯内存,客户端需要自己实现,无持久化
    	redis:性能可靠,纯内存,自带分片,集群,哨兵,支持持久化,几乎成为当前的标准方案
    2)特点
    	缓存策略:缓存与db的边界需要架构师去把控,重度依赖可能引发问题
    	(memcache造成db高压案例,模拟请求解决 → squid;redis短信平台故障案例)
    	缓存陷阱:击穿,穿透,雪崩
    	数据一致性:删除、双写
    

    2.5 应用集群

    2004-2005,淘宝V2.0,EJB为核心(2011年间EJB3 pk spring3.x选型案例)。V2.1架构下,引入spring
    

    在这里插入图片描述

    框架走向轻量化和集群
    1)方案
    	apache:早期负载均衡方案,性能一般
    	nginx:7层代理,性能强悍,配置简洁,可以携带lua完成前端逻辑,当前不二之选
    	haproxy:性能没问题,可做7层或4层代理。
    	lvs:4层代理,性能最强,linux集成,配置麻烦
    	h5:硬件负载,财大气粗的不二选择
    2)特点
    	session保持:集群环境下,用户登陆及session的保持成为问题,需要分布式session做支撑
    	分布式协同:分布式环境下对资源的加锁要超出线程锁的范畴,上升为分布式锁
    	调度问题:调度程序跑重复
    	机器状态管理:多台应用机的状态检测与替换需要做到及时性
    	服务升级:滚动升级成为可能
    	日志管理:日志文件分散在各个机器,促进集中式日志平台的产生
    

    2.6 读写分离

    早在2003-2004淘宝V1.0就使用mysql就使用了读写分离,V1.1换成oracle,直到2007数据库重新往
    mysql回迁,新东方也是相同经历。
    

    在这里插入图片描述

    1)方案
    	缓存集群:redis哨兵,集群,分片,pre-sharding,memcache一致性hash
    	数据库集群:一主多从、双主单写、灾备 (供销灾备双主单写案例)
    2)特点
    	数据延迟:准实时,单方法内的写入立即读取问题
    	开发层面:需要开发框架具备多数据源的支持,以及自动化的数据源切换
    	数据分片:memcache需要客户端处理,redis支持集群数据分片
    	单库瓶颈:业务越来越多,表数量越来越多。单库成为瓶颈
    	数据局限:依然无法解决单表大数据的问题,比如订单积累达到亿级,即使在从库,关联查询依然奇慢无比
    

    2.7 分库分表

    2004-2007,淘宝V2.1,支持分库,抛弃EJB。
    

    在这里插入图片描述

    1)方案
    	早期分区表:range,list,hash,key,对开发端透明,但分区数有限制,性能提升有天花板。
    	业务分库:订单库,产品库,活动库,会员库
    	横向分表:3个月内订单,半年内订单,更多订单
    2)特点
    	(恒天集团基金系统从数据库分区表到Mycat)
    	分库:无法使用数据库事务保证完整性,而分布式事务的效果并不理想,多采用幂等和最终一致性方案。
    	分表:数据聚合矛盾,以订单为例,下单时间维度的分表和用户维度的查询是一对矛盾。排序统计变得
    	异常困难。
    	中间件:Sharding-JDBC,Mycat,Atlas
    

    2.8 动静分离

    早年间的Apache+tomcat,后被nginx几乎一统江山。(前后端开发模式的演进:mvc页面嵌套→接口化)
    

    在这里插入图片描述

    1)方案
    	静态响应:tomcat对静态文件响应一般,提取静态文件,直接由nginx响应
    	动态代理:后端api通过代理转发给tomcat应用机器
    2)特点
    	开发层面调整:项目结构要同步调整,由原来的一体化mvc转换为后端api+前端形式。
    	前后协调:前后端的分工变得更明确,互相并行开发,独立部署,但也带来了接口协调与约定等沟通问题
    	单层局限:单个nginx代理在并发处理任务时,依然会有上限,静态文件节点需要面临扩容。
    

    2.9 多层代理

    2010-2012 ,新东方网络课堂项目架构,基于springMVC+Mybatis,war包集中式部署。资源不够,机器来凑的时代(30台tomcat)。
    

    在这里插入图片描述

    1)方案
    	多层代理:在nginx前再加一层lvs做代理,作为流量的统一入口,再分发给下层的多个nginx,静态服务得到扩容
    2)特点
    	机房受限:lvs依然是单一节点,即使keepalived做到高可用,流量仍然需要在唯一入口进入。
    

    2.10 跨机房

    淘宝V2.1时代 , 使用自己的TaobaoCDN。中国供销集团两地灾备,DNS轮询北京机房,西安机房
    

    在这里插入图片描述

    1)方案
    	dns轮询:通过配置多个ip将服务部署到多个机房,通过dns的策略轮询调用,可以实现机房层面的扩容
    	CDN:就近原则,使用户获得就近的机房访问相关资源,自己投资太大,购买他方需要付费。
    2)特点
    	基本解决了机器部署的扩容问题,随着业务的发展,数据呈现多样化发展,底层异构化数据成为新的瓶颈。
    

    2.11 异构数据

    2006-2007,淘宝V2.2,分布式存储TFS,分布式缓存Tair,V3.0 加入 nosql Cassandra,搜索引擎升级
    数据库查询调优极限→搜索引擎、本地上传+nfs→文件系统的演进,方案后期均有深入讲解
    

    在这里插入图片描述

    1)方案
    	nosql:商品特殊化属性,mongodb,hbase
    	搜索引擎:商品信息库,lucene,solr,elasticsearch
    	分布式文件存储:商品图片,上传的文件等,hdfs,fastdfs
    2)特点
    	开发框架支持:存储的数据多样化,要求开发框架架构层面要提供多样化的支撑,并确保访问易用性
    	数据运维:多种数据服务器对运维的要求提升,机器的数据维护与灾备工作量加大
    	数据安全:多种数据存储的权限,授权与访问隔离需要注意
    

    2.12 业务线拆分

    以上架构的演进,基础设施层面的优化几乎达到了天花板,接下来,需要从业务和应用层面进行架构上的升级
    

    在这里插入图片描述

    1)方案
    	业务分发:代理层设置不同的二级域名,如b2b.abc.com,b2c.abc.com,分发给不同的服务器
    	消息互通:服务之间使用mq等异步消息提供通讯。
    	跨域问题:因为多个业务线占据不同的域名,出现多个主站,单点登录被推上前线
    2)特点
    	粒度较粗:纯以业务为导向,往往形成业务团队各自为战,新业务线出现时疯狂扩张
    	重复开发:相同功能可能在不同业务的项目中被重复开发,比如促销、短信发送、收银台
    

    2.13 服务化

    淘宝V3.0,HSF出现,服务化导向,架构师忙于SOA和系统关系的梳理。
    (2015年冬金融项目业务线rest→dubbo2.4.11的引入过程)
    

    在这里插入图片描述

    1)方案
    	公共服务:重复开发的基础服务沉淀,形成服务中心,避免重复造轮子,降低成本,架构团队出现。
    	独立性:各自服务独立部署升级,粒度更细,低耦合,高内聚
    	SOA:服务治理的范畴,重在服务之间的拆分与统一接口
    	微服务:可以理解为服务治理的一种手段,趋向于小服务的独立运作与部署。
    	技术手段:springcloud,dubbo
    2)特点
    	界限把控:服务的粒度、拆分和公共服务提炼需要架构师的全局把控。设计不好容易引发混乱
    	部署升级:服务数量增多,自动化部署面临挑战
    	服务可用性:抽调的微服务因需要被多个上层业务共享,可用性等级变高,一旦down机就是灾难
    	熔断和限流:做好服务熔断和限流,提防服务单点瓶颈造成整个系统瘫痪。
    

    2.14 中台化

    阿里共享业务技术部的发展,中国供销集团,电商平台中台体系的架构模式。
    技术沉积形成了公共服务平台,业务沉积逐步形成共享业务技术部,同时,业务烟囱的壁垒推动业务中台成型。同时组织结构同步升级,以技术共享为核心的技术中台,以数据为中心的数据中台同步建设得到实施。
    

    在这里插入图片描述

    1)方案
    	业务沉淀形成独立的中心,各个中心之间借助服务总线实现业务协作与服务重组。
    2)特点
    	团队规模:团队规模扩张,人员增多,协调成本上升,组织机构要有配套调整
    	接口授权:各个中心的接口授权与开发需要把控
    	接口约束:系统增多,各个服务接口的规范化日益重要,要求有统一的服务接口规范,推动企业消息总
    	线的建设
    	跨服务令牌:借助oauth2等手段,实现服务之间的权限认证
    

    2.15 容器化

    针对中台化的建设及微服务数量的飙升,部署和运维支撑同步进行着变革。面临微服务的快速部署,资源的弹性伸缩等挑战,容器化与云被推进。
    案例:成百上千的服务数量庞大、大促期间某些微服务的临时扩容。
    

    在这里插入图片描述

    1)方案
    	虚拟化:vm方案,Openstack,Vmware,VirtualBox
    	容器化:docker
    	编排:swarm,k8s,k3s
    	云化:容器化解决了资源的快速伸缩,但仍需要企业自备大量预备资源。推动私有云到企业云进化
    2)特点
    	资源预估:注意资源的回收,降低资源闲置和浪费,例如大促结束后要及时回收。
    	运维要求:需要运维层面的高度支撑,门槛比较高
    	预估风险:云瘫痪的故障造成的损失不可估量,(openstack垮掉的事故案例)
    

    3 架构总结

    1. 知行合一,做之前,先考虑意义
    2. 原生优于定制,约定大于配置
    3. 什么都是,最后会沦落到什么都不是
    4. 控制技术欲,不要瞎折腾
    5. 留下扩展,但不要想到100年后
    6. 没有最好的,只有最合适的
    7. 够用就好,玩的越花,风险越大
    8. 简约最美
    
    展开全文
  • 摘自《一本书读懂5G技术》,王振世 著,第一章 第三节

    摘自《一本书读懂5G技术》,王振世 著,第一章 第三节

    展开全文
  • 摘要:本文将带大家详细了解NB-IoT标准演进与产业发展
  • 2.WLAN的发展历程

    2021-08-10 09:58:40
    WLAN的发展历程WLAN的发展历程一、802.11系列标准1.802.11协议体系结构图2.IEEE 802.11MAC子层支持的物理层标准①IEEE 802.11 FHSS物理层②IEEE 802.11 DSSS物理层③IEEE 802.11IR物理层④IEEE 802.11a物理层⑤IEEE ...
  • 世界上大多数事物的发展规律是相似的,在最开始往往都会出现相对通用的方案解决绝大多数的问题,随后会出现为某一场景专门设计的解决方案,这些解决方案不能解决通用的问题,但是在某些具体的领域会有极...
  • 为便于使 用和大批 量 生产 ,进一步发展了可编程只读存储器(PROM)、可擦可编程序只读存储器(EPROM)和电可擦可编程只读存储器(EEPROM)。EPROM需用紫外光长时间照射才能擦除,使用很不方便。20世纪 80 年代制...
  • 一、电商系统演进

    2021-09-21 16:32:45
    1.业务模式演进 1.1发展历程 1.1.1萌芽期 1.1.2发展期 1.1.3稳定期 1.2业务模式 1.2.1B2C 1.2.2C2C 1.2.3B2B 1.2.4O2O 1.2.5其他 1.3电商中台 1.3.1背景 1.3.2概述 1.3.3业务中台 1.3.4技术中台 ...
  • 随着移动通信技术的更新迭代,逐渐提升的网络速率能为用户带来更加丰富的移动互联网应用。如前文所述,通信技术的更新迭代推动移动互联网的快速发展,从而改变了人们的生活和娱乐方式。3G时代,以图文...
  • Intel CPU 微架构的演进发展

    千次阅读 2021-11-21 22:11:25
    title: Intel CPU 微架构的演进发展 date: 2021-11-21 22:10 author: gatieme tags: - linux - architecture - intel - pipeline categories: - 技术积累 thumbnail: blogexcerpt: Intel CPU 微架构的演进发展 ...
  • 分布式消息队列的演进

    千次阅读 2021-10-01 00:35:17
    作者:vincentchma,腾讯 IEG 后台开发工程师一、消息队列的演进分布式消息队列中间件是是大型分布式系统中常见的中间件。消息队列主要解决应用耦合、异步消息、流量削锋等问题,具有高...
  • 答案:段 6【判断题】 存储器元件只读存储器ROM的发展演进的先后顺序是MROM、PROM、UVEPROM、EEPROM、Flash。 答案:√ 2.3 磁盘存储器 1【单选题】 根据磁表面存储原理,所采用的数字磁记录格式中,()不具有自...
  • 1 前言OPPO的大数据离线计算发展,经历了哪些阶段?在生产中遇到哪些经典的大数据问题?我们是怎么解决的,从中有哪些架构上的升级演进?未来的OPPO离线平台有哪些方向规划?今天会给大家一一...
  • 数据库服务和架构演进——从开发者需求看数据库的发展数据库服务和架构演进——从开发者需求看数据库的发展 数据库服务和架构演进——从开发者需求看数据库的发展 整理自:第十一届数据技术大会 演讲人:腾讯云...
  • NFC技术演进

    2021-03-30 11:05:45
    RF演进 protocol 演进
  • 服务器端的架构演进   早些年,在所有程序员眼中BAT可谓是宇宙厂,是很多人的终极目标。可是谁也想不到当初BAT像依赖氧气一样依赖IOE(IBM:服务器提供商,Oracle:数据库提供商,EMC:存储设备提供商)。有这样一...
  • Kubernetes 的快速演进大大推进了云计算技术的发展,伴随着云原生计算基金会CNCF的诞生、云原生开源项目的孵化,逐渐演化成一个完整的云原生技术生态系统。 本文就来介绍一下Kubernetes与CNCF的关系、Kubernetes演进...
  • 从表面上来看,元宇宙是一夜之间火爆起来的,实质上,元宇宙的衍生和成熟并不是一蹴而就的,而是经历了一系列的发展演进。  提及元宇宙,人们更多地想到的是元宇宙在游戏里的应用,原因在于通过元宇宙,我们实现...
  • 简介:随着云原生理念与云原生技术的不断完善和发展,越来越多的行业开始落地实践云原生技术,这对不同岗位的技术从业者产生了不同程度的影响。不管是对 IT 主管还是对一线开发人员和运维人员来说,从业务逻辑到技术...
  • 概述 今天主要分享珍藏的几张Oracle体系架构图,感悟Oracle数据库设计的博大精深! ORACLE 8i 视图体系 Oracle9i体系架构 Oracle10gR2体系架构 Oracle11g体系架构 Oracle12c体系架构
  • 2月23日,在上海举行的第23届GTI国际产业峰会上,中国移动联合近20家国内外主流运营商和厂商,共同发布《5G无线技术演进白皮书》。这是业界第一次联合发布关于5G无线发展演进的白皮书,标...
  • 此外,我们还衍生发展了基于智能手机/平板的图传产品: MPU/MCP用于产生视频,就是DVS(数字视频服务器),相当于一台单兵、一台车载机DVR或者一个高清网络摄像机HDIPC,它采集视频,压缩编码、然后应客户client要求...
  • 演进式数据架构

    2021-01-27 15:37:00
    这是《演进式架构》这本书第一章第一节对“演进式架构”的作用做出的简洁定义,也就是说演进式架构便是持续架构,因为在架构这件事上没有最终状态,它会随着软件开发体系的不断变化而演进,我们只能将时间和变化作为...
  • 区块链P2P网络协议演进过程

    千次阅读 2021-09-15 17:03:18
    以太坊的P2P网络及节点发现 以太坊是在比特币基础上发展而来的,借鉴了很多比特币的思想,就连白皮书都有一半内容是描述比特币的功能。所以以太坊不仅能够实现类似比特币的交易系统,更希望构建基于区块链的生态...
  • 机器人三大定律的发展演进概述

    千次阅读 2021-01-18 19:47:09
    贯穿阿西莫夫宇宙的线索看似是两个银河帝国的发展历程,但实际更是人类从地球走出太阳系,走向银河系的过程,也可以说是人类对机器智能从依赖到融合,再到拒绝,到最后无形中被机器的超人工智能引导向更高层次生命...
  • NVIDA GPU架构演进

    千次阅读 2021-03-21 09:52:55
    GPU发展时间表 GPU架构的更新主要体现在SM、TPC的增加,最终体现在GPU浮点计算能力的提升。 Kepler架构: FP64单元和FP32单元的比例是1:3或者1:24;GPU型号K80。 Maxwell架构: FP64单元和FP32单元的比例下降到了...
  • 架构演进

    2021-03-06 23:36:51
    概述 技术作为业务的支撑,它永远是伴随着业务的发展发展,我们需要不断的学习新的技术去解决新的问题。 但是伴随着年龄的增长,我们能够投入的时间和精力越来越少,掌握科学的学习方法,使用自己的思维方式、对...
  • 计算机网络演进之路

    2021-06-28 08:20:44
    其中发展最快并起到核心作用的是计算机网络。计算机网络向用户提供的最重要的功能是连通性和共享。2. 因特网概述2.1 "网络的网络"网络有若干个节点和连接这些节点的链路组成。只有一台孤立的计算机干不了什么事情,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 73,953
精华内容 29,581
关键字:

发展演进