系统架构设计的出发点是帮助系统的用户使用现代化手段完成各项工作，其本质是“业务流程”，而不是一个计算机系统或者计算机应用。       在这一原则之下，普遍系统整个业务功能的设计和实现通常采用SOA（面向服务的体系架构），充分保证系统功能和流程实现的灵活性和扩展性。

作者：金雪锋文章链接：https://www.zhihu.com/question/524596983/answer/2421526288288稍微有点意外，因为去年Jeaf Dean公布Pathways的时候，感觉更像是模型的架构，但这次放出来的是AI Infra的内容，我猜测要不就是Pathways论文讲的基础设施对训练类似多任务/多模型态这些大模型非常关键，要不就是还有一篇专门讲模型的论文。论文首先分析了当前AI框架主流的两种调度模型优缺点：一种是multi-controller架构即典型的HPC中的SPMD，当前Pytorch/JAX/TF2都是这种架构，MindSpore也是类似的。如 (a)所示，每个client在host侧运行，负责自己机器上的device的computation分发。优点：1) 自己host给自己device分发任务，走的是快速的PCIe通道；2) 跨host的通信走的专用的链接（NVLink，或ICI），不借助host memory。缺点：1) 很难实现流水线，用户需要自己实现coordination primitives；2) 当前只允许独占集群，不能执行多作业共享集群资源。缺点一，个人感觉比较牵强，因为multi-controller的架构实现流水线编排感觉是没有问题的，而且还可以发挥多controller并行编译的优点。另外一种就是single-controller典型的如TFV1，client通过构建计算图，将其交给coordinator，后者进一步将图划分，划分后的子图分配给各个worker执行。优点：1)提供了灵活的编程方式，支持流水线并行等non-SPMD方式2)允许资源的virtualization。缺点是：1)在分发computation时，涉及到跨数据中心网络(DCN)的通信，如图(b)；（不高效的原因是每轮迭代都要回到ctlr，像google的tpu集群，一个pod256chip，512核，跨pod不能走高性能总线，跨POD通信会比较慢，而从ctlr下发和返回都会涉及跨POD的通信）2)当涉及到的算子数量巨大时，分发computation和coordiantion开销太大(图(c))。Pathways的设计目标：MPMD，融合multiple-controller和single-controller的优点client/host：用户Python代码执行侧，最后转换为low level的MLIR；Resource Management：设备管理，让用户不需要感知具体执行在哪个物理设备上；自动分配的节点可以最大化利用带宽；用户无需感知mesh是2D还是3D；coordinator and gang-scheduler：Low-level IR会转换成PLAQUE program （谷歌内部一个闭源runtime系统），PLAQUE起到了coordinator底座的作用；多调度器架构，每个island会有一个单独的runtime scheduler，负责调度本island中的computation。达成在本island中一致的执行序。现在的调度算法是FIFO。Data management： sharded object store，类似ray。计算中间数据存储在obj store中，function间的通信也是走这个；1、编程模型我们首先看一下Pathways的编程模型：1、首先有一个virtual device的概念，用户编程的时候指定需要的设备数量，不需要指定具体物理设备，由框架来选择具体物理设备；具体的设备资源的分配应该是resource management去完成2、通过pmap实现切图和切算子的能力，我理解程序中a/b/c这些切出来的子图应该后面plaque调度的最小单元。3、通过pw.program的修饰符，实现多种client下发执行的模式。论文中提到pathsway有OpByOp、Chain、Fuse多种执行模式，我想可能是通过前端这种修饰符来指定的。2、调度模型任务下发：论文中提到Sequential dispatch和Parallel async dispatch，我不知道为什么论文中大篇幅介绍了相关内容，感觉是比较自然的事情：Coodinator+island两级调度：首先计算图按照切分规则被分发到不同的coodinator，coodinator的个数应该是灵活的，不过比较容易想到的规则是一个pod一个coodinator（这样的好处在于POD间带宽较低，避免让coodinator去管理其他POD的调度）；每个coodinator的子图再由island的runtime来调度，这里最大的挑战是coordinator之间的数据同步，因为和SPMD的程序不一样，MPMD在不同的coordinator跑的图可能是不一样的，所以他们之间的数据同步使用传统的MPI原语有可能有些困难，所以论文中提到使用类似Ray的共享内存的方式来做。资源共享：我个人觉得，最关键的一点是，计算图进行灵活的并行切分后，有机会发现资源空隙，插入其他的计算任务。效果：当单个computation的时间大于2.3ms时，16 hosts 上的pathway能够match上Jax。这是因为计算时间完全掩盖了coordination时间。多租户的效果多clients的利用率总结：Pathways试图提供一种MPMD的调度模式，使能AI计算的云化；解决当前架构有三个问题：（1）灵活性不足，不能满足流水线并行等细粒度并行机制；（2）计算资源独占，在异构集群中资源利用率低；（3）无法满足基础模型中多任务复用、稀疏计算等需求。其核心在于：1、虚拟资源管理2、并行图切分：图和设备的灵活映射、基于共享内存的数据同步；本质是图上能充分表达动态路由和稀疏计算的并行性3、多级调度：client/coordinator/island，实现资源的共享复用。问题和疑惑：1、看上去任务的切分只是支持静态shape，动态shape的场景会导致底层的调度无法预估资源；2、当计算的节点融合到足够大，效果才与multiple-controller架构接近；所以op by op这些执行模式效果不会太好。3、如果计算任务做不到并行图切，比如是数据并行的话，可能资源很难空闲，不知道是否有资源复用的效果；4、多租户这一块要做到计算复用，个人感觉重点在于内存要足够大，放得下多租户的权重和激活，但是现实是现在许多训练任务的瓶颈都在内存上，另外还有一个问题就是动态shape场景下，算不出内存占用怎么办。或许Pathoways这样的AI Infra比较适合Pathways这样的模型。

本文说明本文总结梳理-NR系统架构,L1、L2、L3功能框架,便于5G系统相关人员快速熟悉整体架构设计,了解关键技术标准和实现方法。不涉及具体技术细节,宏观把控即可。15G 系统架构与E2E网络切片架构图1 网络切片架构示例E2E(端到端)架构图2 E2E架构示例4G 与5G QOS架构的区别图3 LTE和5G QoS架构比较频谱共享架构图4 频谱共享架构简图图5 5G传输网络参考架构框架的示例4G 与5G互联分离架构图6 简化的4G和5G互联架构图7 3GPP考虑的具体4G/5G互联选项2RAN架构图8 LTE与5G的UP处理比较图9 在5G多服务和多租户RAN中实例化NF的示例图10 根据不同的部署场景进行3层RAN功能划分图11 高层SD-RAN架构3传输网架构图12 融合异构网络和计算基础设施图13 5G传输控制面架构图14 面向租户切片概念图15 传输网一般架构4网络切片图16 网络分片的关键原则图17 特定网络功能/配置的服务或切片示例图18 在跨供应商业务流程上进行切片图19 端到端网络切片示例,用于工厂的5G业务图20 网络切片生命周期管理的各个阶段55G-NR思维导图为方便从事无线通信协议开发、FPGA开发、基带芯片开发或RRU开发工程师们,特别是刚进入通信行业的新人,更快地了解NR的框架,笔者绘制了一份简单的NR思维导图。对于L2、L3,由于平时涉及和了解不多,就简单标识。我们重点把握L1部分,即PHY物理层的关键技术。图21 5G-NR思维导图更为完整和详细的说明,可去参考3GPP TS38系列技术规范和相关的提案。如果有对RRU感兴趣的朋友,比如对DPD算法、AD/DA、高速接口、MIMO等熟悉的朋友,可否传授一些经验,笔者前来学习学习。为了更完整的了解5G的基站与终端之间的PHY处理过程,下面笔者从相关资料种整理了两张图,分别描述了下行和上行物理层处理过程。55G 下行与上行处理过程下行处理:从基站到UE。下图非常清晰地说明了从发送到UE接收的全过程。图22 整体下行物理层处理过程上行处理:从UE到基站。下图非常清晰地说明了从UE发送到5G基站接收的全过程。图23 整体上行物理层处理过程关于5G系统架构和NR协议的介绍就到这里,更多内容,后期推出。这里抛一个问题:5G会是失败的一代通信技术吗?你怎么看?欢迎留言讨论。参考1．5G System Design．2．5G NR Architecture, Technology, Implementation,and Operation of 3GPP New Radio Standards．

现在网上讨论的有关物联网的咨询非常之多，但大部分都是介绍理论或者有关硬件，通讯相关的问题，比如物联网模块，物联网通讯协议MQTT、XMPP、NB_IOT等，个人认为这些只是物联网中一部分，而涉及到物联网的设备如何管理，用户如何管理，数据包如何解析，大数据如何展示等也是物联网模块中非常重要的部分，所以作者就根据自身工作中总结出来的建构在云端的物联网平台基本架构分享给大家，并基于此架构如何一步一步来开发一套物联网平台。物联网平台，应该是基于现在的互联网，通讯技术来建构，而不依赖与特定的硬件模块，用户可以基于自身的设备技术架构，简单轻松接入物联网。下图是物联网的核心架构：1. 四大核心模块在物联网中存在4大核心模块，那就是设备管理，用户管理，数据传输管理，数据管理，只有具备了这四大核心模块，才能认为是一个完整的物联网平台，而所有其他的功能模块都是基于此四大功能模块的延展。1.1 设备管理 设备类型管理：定义设备的类型，此功能一般由设备的制造商来定义，一种设备类型最重要的是关联到一套独有的数据解析方法，数据的存储方法，已经设备规格等数据，也只有设备的制造商才可以编辑有关设备类型的数据，而设备的使用者只能浏览设备类型的相关信息设备管理：设备管理定义设备相关信息，每个设备必须定义其设备类型，设备类型有使用者属性，设备在完成销售，并被使用者激活后设备就属于设备使用者了，这时候设备使用者对设备有完全的控制权，可以控制设备的哪些数据可以被制造商查看，可以被哪些用户查看等权限1.2 用户管理组织管理：在物联网平台中一个很重要的观念就是组织，所有的设备，用户，数据都是基于组织的管理的，设备制造商是一个组织，设备的使用者是一个组织，家庭都可以是一个组织。用户管理：用户是基于一个组织下的人员构成，每个组织下面都有管理员角色，管理员可以为其服务的组织添加不通的用户，并分配每个用户不同的权限。一个用户也可以属于多个不同的组织，并且扮演不同的组织。 用户组：一组用户，也是基于组织的用户组管理，同一用户组的用户拥有相同的权限权限管理：同样是基于组织的权限管理，主要是针对对象级别的权限细分，如设备的浏览权限，可以控制每个用户是否看到这个设备；设备数据浏览权限定义是否可以查看设备的运行数据1.3 数据传输管理1.31 基本格式数据传输管理，定义针对一类型设备的数据传输协议，基本格式是:每一个设备有厂商唯一的序列号，因为每个制造商有自己的编码格式，固此序列号没有固定格式。命令码，为此条数据的作用，比如是上传数据，或者服务器下发给设备的命令等，一般采用2位数字编码00~99数据，此部分是此条报文，所包含的数据部分，每个协议可以定义不同的解析方式，比如服务器在收到数据包后，会根据预先定义好的解析方式解析数据字段，并按照规则存储1.32 数据解析定义每种设备类型可以定义多条命令，每个命令都有自己不同的解析方式，组织的管理员可以为自己的设备类型定义解析方式，服务器接收到数据后，会自动根据预先定义的解析方式解析数据字段，设备开发者要根据在IOT平台定义的数据格式，自行开发自己设备的解析代码，数据字段都按照HEX方式收发。1.33 数据的存储存储要支持分布式架构，可以为每个设备定义不同的存储位置，在diego iot中数据存储使用mysql数据库，实现不同的设备存储在不同的mysql数据库中每条数据定义生命周期，在生命结束后，系统将自动删除1.4 数据管理 权限管理，数据的权限在物联网平台中是至关重要，数据属于谁是一个非常重要的概念，只有设备的拥有者才能定义数据可以给谁看；大数据，物联网数据本身就是海量的数据，我们可以借助一些开源的大数据平台来实现数据的可视化分析，只有经过分析的数据才是有价值的数据；数据的导出，用户可以导出数据到本地做分析；2.网络通讯现在所有的云端的物联网平台和设备之间的通讯，本质上都是建构在TCP/IP协议之上的，只是对数据包的再封装而已，基于此我们可以是用wifi，4g来实现设备和云平台的通讯，不过设备与设备之间的通讯，可以有wifi，Bluetooth，zigbee等，下面介绍几种常用的通讯架构2.1 基于移动3/4G通讯此架构是最简单的架构，设备就如同我们的手机，基于移动通讯来上网，其主要需要考虑如下几点：每个设备都需要一个SIM卡，可以到移动服务器商办理专门针对物联网的SIM卡；数据流量问题，这种架构完全是走数据流量，如果有视频数据，将会产生比较大的流量费用，这都是要考虑的；通讯质量问题，这完全依赖于移动服务商的网络覆盖状况，就如同我们手机一样，在有些环境下是没有信号的，也就没办法收发数据；2.2 基于wifi局域网此中架构，适合于所有的物联网设备都是运行在一个局部环境中，设备通过wifi或者有线连接到路由器，而由路由器统一连接的物联网服务器，就如同我们家中装一个wifi路由器上网一样的架构，需要注意的事项：1.局域网内的智能设备，是没有公网独立的ip的，只有一个局域网内的ip，带来的问题就是，设备可以直接给物联网服务器发送数据包，而物联网服务器是不能直接给设备发送数据包，就因为设备没有公网独立ip2.功耗问题，对于使用wifi接入的设备，最好不是电池供电，因为wifi的功耗比较大3.干扰问题，如果在大型的厂房部署这种架构，一定要考虑，厂房内是否有强干扰源，如电磁干扰，可以考虑采用工业级的无线路由器，一般抗干扰能力比较强2.3 基于蓝牙通讯一般的基于蓝牙的物联网，会考虑通过蓝牙网关来部署蓝牙由于其点对点的通讯方式，所以要考虑如下问题：1.蓝牙网关的容量问题，也就是一个蓝牙网关能接入几个蓝牙设备，这取决于蓝牙网关中使用了多少个蓝牙设备2.蓝牙的配对问题，蓝牙设备直接的通讯都首先配对才能通讯，如果实现自动配对，如果不能自动配对，大规模部署，将是一个很麻烦的事情还有一种场景是针对不需要一直在线的物联网设备，而只是在某种特殊需求的情况下，需要连上服务器，这中场景下，我们可以通过手机的蓝牙功能来让设备接入物联网蓝牙手环是这种架构的一种典型应用模式2.4 基于zigbeeZigBee也是一种流行的组网模式，zigbee本身设计是针对传感器之间的联网，具有非常强的低功耗能力。zigbee接入网络也依赖于zigbee网关，网关本身也是一个zigbee设备，zigbee设备是自组网的，在使用过程中注意的问题有数据量的问题，设备能力和功耗本身是自相矛盾的，由于ZigBee是超低功耗方案，固在通信能力上也是打折扣的，很适合一些传感器数据的采集，如温度湿度，但如果对大数据量的视频类的就不适用了这里主要介绍了，几种常用的物联网部署架构，至于物联网协议，这里就不多介绍，网上文章非常多。3.智能设备diego iot设计的初衷是让智能设备开发者摆脱对特殊模块的依赖，对于智能设备的开发，只要具备联网功能即可，没有特别多的要求。————————————————原文链接：https://blog.csdn.net/ly_asmt/article/details/121125324

>摘要：在云原生2.0阶段，我们到底需要构建一个什么样的架构？华为云首席架构师为你一一解答。本文分享自华为云社区[《华为云首席架构师独家分享：云原生2.0架构设计的8大关键趋势》](https://bbs.huaweicloud.com/blogs/314122?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)，作者：技术火炬手。 云原生2.0是企业智能升级新阶段，企业的云化从“ON Cloud”走向“IN Cloud”，当一切应用都生于云，长于云，云架构的迭代也会进入一个新的阶段。 围绕云原生2.0，**华为云首席架构师顾炯炯提出了8个关键模式：** 分布式云，混合调度，应用驱动基础设施，存算分离与数据治理自动化，可信、平民化DevOps，基于软总线的异构集成，多模态可迭代AI模型，全方位立体式云安全。 # 分布式云 随着云化和数字化渗透到制造类、工业互联网类场景，5G技术在to B领域应用的快速成熟，以及物联网 、AI技术的成熟，现在云的服务对象不仅是企业的后台IT支撑系统，它延伸到了前端的“现场”，类似于工业场景里的近场计算。如果还是将所有的数字化应用系统都放在集中的数据中心，它的时延无法满足实时生产系统的要求。 另外，有一些行业的敏感数据不能从现场或者数据产生地直接简单的上传到云端，它存在数据安全、隐私保密的问题。再比如医疗里的基因大数据、视频监控等场景，如果所有数据都上传到云端，带宽的成本非常高昂。 所以，我们必须要**引入云边端协同的分布式概念，构建分布式云的架构。** 这个架构可以和核心侧架构配合，覆盖核心区域、热点区域、本地机房、业务现场等不同接入时延敏感度，数据隐私合规要求及数据上云带宽成本的应用上云场景。 举个例子，通过这样的方式，可以把云端的很多算力和计算逻辑，甚至是训练好的AI模型推送到更加靠近用户数据产生地的位置上，进行就近的计算，将海量的数据做一定的收敛、分析、脱敏等，再发送到云端进行闭环的处理和控制反馈。 # 混合调度 在很多算法专家的努力下，华为云通过瑶光调度平台大大提高了资源的分配效率，达到甚至超过了80~90%的程度，已经接近于业界的领先水平。但是资源的实际利用率仍然处在一个比较低的水平，当然业界平均也不是特别理想，领先者差不多20%左右。为了解决这样的问题，**华为云引入混合调动、柔性计算的能力，将在线和离线的不同优先级的业务，进行QoS感知的智能调用，实现资源利用率最大化。** 柔性计算不仅仅具备弹性的特征，保证了横向的资源扩展，而且它也能实现纵向资源规格的可大可小。目前，消费者云已经在内部验证了柔性计算的能力，可以在不改变上层业务的前提下提高利用率，实现性能的倍增。关于柔性计算的更多内容参考 华为云首席架构师顾炯炯：[敢为人先，探索架构创新之路如何走。](https://bbs.huaweicloud.com/blogs/314131) # 应用驱动的基础设施 如今，软硬件的垂直整合，特别是靠近操作系统底层的硬件和云服务基础设施层的服务软件之间的纵向整合能力，成为新的趋势，它把基础设施服务底层的硬件和相应的服务封装层打包在一起。 云服务厂商可以设计研发定制芯片，比如存储和网络的硬件卸载的芯片、匹配深度学习逻辑处理框架的芯片等等。如果有能力构建这样的软硬件垂直整合的能力，就能拥有相比其他云服务商更优的价格优势，也得以呈现自身独特的硬件、芯片优势。 有了应用驱动的基础设施之后，**根据应用的性能SLA需求，来定义是使用与软件完全解耦的通用硬件资源，还是匹配应用场景特殊诉求的软硬件深度协同的卸载卡或异构计算资源。** 这也能发挥华为软硬件兼长的优势，我们在硬件领域有不少核心创新：**一个是 SDI**， 叫软件驱动的基础设施，也就是把分布式存储\分布式网络，还有Hypervisor的一些系统能力从服务器卸载到PCI卡上，也即SDI/擎天卸载卡。二是**鲲鹏硬件支撑云存储和数据湖的处理**， 鲲鹏单核处理能力虽弱于X86，但核密度则达到X86 CPU的2倍，因此在对IO及内存带宽作为其性能瓶颈的大数据及分布式存储场景，是比X86更好的选择。同时，我们也在用自研的**昇腾NPU取代GPU构建AI平台**， 它在深度学习的训练推理中体现出更高的能效比。 # 存算分离和数据治理的自动化 未来企业的所有的数据孤岛都将汇聚到云端的数据湖，进行统一生命周期的治理和管理，所以必须要解决数据计算分析的资源需求。数据湖里有各种各样的结构化、半结构化、非结构化的数据，**但这些数据的分析计算和底层的存储容量之间的需求，并不是线性匹配的关系。** 比如对于深度学习的场景，数据量需要不断的计算迭代，它需要更多的计算能力，相对较少的存储需求。因此在不同的业务场景下，数据分析计算和存储的要求是不一样的，最终一定要走向存算分离。 在存算分离领域里面，华为云已经积累优势，从最早的去中心化的分布式存储引擎FusionStorage开始，七年磨一剑，我们从内部验证到向外部的推广，从块存储延伸到对象存储、文件存储、分布式的集群数据库，把原先在开源架构里五花八门的底层存储技术引擎架构实现了统一。经过实际的测试，在业界同样支持存算分离数据湖架构的云场景中，华为云体现了领先30-60%以上性能优势。 **再就是数据治理自动化。** 现在的数据治理的还是人力密集型工作，整个过程非常低效，很难满足很多行业的要求。所以在这个架构模式里面，除了存算分离的数据库，还要构建数据治理自动化。 通过引入AI的技术，将数据的获取、清洗以及最终数据知识的提取，主题库的建立、数据目录的发布，都实现完全的自动化。用户只需要指定入湖的数据源和所属业务主题域，系统自动化创建入湖任务，底层资源根据入湖数据量自动扩缩容，智能完成入湖数据的安全等级、分级分类、隐私等级等数据标签的自动识别打标。这个能力对企业数据资产的快速沉淀能力的构建是至关重要的。 # 可信、平民化DevOps **通过将一系列安全可信措施嵌入到敏捷开发运维模式，** 构建所谓的DevSecOps流水线，实现敏捷快速迭代与严格质量管控兼顾；并**通过低代码/无代码实现更多行业应用资产的沉淀**， 将行业应用的开发效率再上一个新台阶。 Devops实现了应用的敏捷开发，但在面向政企时，还需要满足应用质量和安全可信的要求。因此在遵循DevOps的同时，将安全能力集成到其中，升级成为DevSecOps。使用安全左移、默认安全、运行时安全、安全服务自动化/自助化、基础设施即代码（IaC）等技术， 实现管理与协同、设计与开发、CI/CD、应用管理、运维、安全可信等各个环节的一体化趋势。 此外，由于传统政企开发投入有限，需要通过低码化无码化，来实现对应用进行快速构建及改造。华为云低代码平台AppCube可支持多种页面类型和丰富的组件能力，基于它的服务能力编排和业务流程无代码定制，可实现灵活流程触发方式、多种权限配置方式、自定义业务编排等。 # 基于软件总线的异构集成 即帮助企业**构建可平滑演进的IT架构**， 实现老旧应用与新建云原生应用，线上与线下应用的平滑融合集成。 云原生下，企业很多应用都要进行微服务解耦，遵从微服务的治理架构，进行水平扩展的架构的设计，甚至把原来的单体架构逐步进行拆解。但这个过程不是一蹴而就的，尤其是那些包袱比较重的传统行业，他们还面临很多现实的挑战。所以我们要在企业传统IT架构和云原生架构之间搭建无缝的桥梁，在确保企业业务连续性最大化的前提下，实现平滑的切换和演进。 以Roma Connect为例，它可以通过软总线的形式，把云原生和非云原生的传统世界无缝的连接起来，支持异构的应用和数据库源的对接，也可以对接到云上开发平台、数据湖，实现无缝互通。 在架构的平滑演进中，首先需要将传统非云原生应用封装为REST接口与云原生应用对接，通过统一接口服务层APIC进行开放，业务云原生应用通过标准接口即可获取老系统信息。同样的机制可以将线上线下，及部署在多云环境上企业IT系统的无缝互通。 其次传统Oracle/Sybase等传统数据库及中间件与设备协议接入上云：云上云原生应用通过云上标准API调用、数据库访问、消息订阅等方式即可获取传统数据。 最后，通过全生命周期的API管理能力，包含从设计、发布、上架、治理的全过程，帮助企业构建整个跨地域，跨组织、跨部门的应用网络，并沉淀行业应用资产。 # 多模态可迭代的AI模型 AI在行业落地面临的问题是能够获取到的训练数据是非常有限的，单纯的依赖数据驱动的深度学习训练，使得行业AI模型是非常难以泛化、通用化。 预训练大模型是解决AI应用开发定制化和碎片化的重要方法。 通过一个AI大模型实现在众多场景通用、泛化和规模化复制，减少对数据标注的依赖，赋能AI开发由作坊式转变为工业化开发，比如华为云之前推出的盘古大模型。 另外也要**引入知识计算的能力**， 类似于把知识图谱这样的能力和基于感知计算的数据驱动的AI模型互补结合起来。也就是说把知识模型和数据模型，在数据样本相对缺少的情况下结合在一起，更好服务于行业AI的落地。帮助企业打造自己的知识计算平台，整合分散在不同系统、多种形态的企业数据，形成带有建议性的知识体系。 # 全方位的立体式云安全 1.0阶段的云安全服务更多的是孤立的安全能力：虚拟化安全，hyporvisor防逃逸能力，云防火墙能力其实都是割裂的，并没有跟所有的云服务形成互锁。 **全方位的立体式运营安全通过打通离散的云安全服务能力，将其与其他云服务及客户应用形式互锁**， 构建安全Build-in的云原生应用，以及引入可信智能计算，解决跨行业数据隐私保护与流通碰撞、价值挖掘之间的矛盾。 首先通过可信智能计算提供四个核心能力，进行安全可信的数据计算。包括： 1、跨组织、跨行业的多方数据融合分析和多方横向与纵向联邦学习建模； 2、支持对接主流数据源和深度学习框架； 3、支持安全多方计算（例如同态加密，差分隐私等），并支持用户自定义隐私策略； 4、基于区块链的数据计算轨迹的可追溯可审计。 此外，为了全方位安全，还需要将全栈云（及其子集）下沉部署（连线/非连线），彻底解决敏感行业上云安全顾虑，以及将全栈云服务、企业新开发云原生应用、aPaaS/SaaS等与全栈云安全能力互锁，为用户构建体系化的云安全平台。

1.1 方案设计1.1.1 方案设计页面注册方案成功后，相应的方案设计负责人（架构师角色）会生成待办事项，在工作待办页面的待处理模块中，点击该事项的处理按钮如下图或者点击菜单栏导航的设计中心标签，或者点击方案管理页面的设计按钮，如下图以上方式都可以进入到方案设计页面，如下图1.1.2 集成架构设计点击方案设计页面中的添加集成架构按钮，可以弹出添加弹窗，如图一、选择无模板：填写信息后确定，添加集成架构后在画布中设计结构图，可以在图元库中选择图元按住左键拖拉到画布中，点击图元，图元的边框上会显示连接接待，选中节点按住左键就可以拉出连接箭头，右键点击图元可以看到相关的图元操作。如下图画布正上方是绘图辅助工具，右上方有保存按钮、导出画布按钮、清空画布按钮、发布加速场按钮。绘制完成后点击保存即可。申请添加至加速场架构模板：保存画布后，如果想将该架构图申请为加速场模板，点击发布加速场按钮（如上图右上角红色线框内）进行申请，申请通过后即可以上架至加速场架构模板。二、选择加速场架构模板：需要复制加速场架构模板的ID填写至ID输入框内，填写完信息后点击确定即可将架构模板导入该集成架构。如下图在选择模板框中输入架构模板的相关信息后搜索，选择目标模板确定。架构模板的相关信息，可以在我的首页页面的解决方案加速场中点击架构模板标签，如下图架构模板名称后面为模板ID，点击复制即可获得ID。三、从已有架构复制：如下图选择需要复制的模板所在的工作空间、解决方案、集成架构名，填写好其他相关信息后即可。1.1.3 部署架构设计一、手工部署：点击方案设计页面的新建部署架构按钮选择手工部署，如下图填写相关信息后确定即可。点击部署架构名称，在右方的配置清单内点击新建配置项按钮，即可添加配置项，如下图二、使用IOTStage：点击方案设计页面的新建部署架构按钮选择IOTStage，如下图填写好相关信息后，点击确定即可。新建IOTStage部署架构后，点击该架构名称，页面展示如下图注意事项：上图右方设计步骤栏中的提示功能非常重要，有具体的步骤指导。点击上图的开始设计按钮，可以进入应用托管平台页面，如下图点击新建应用按钮，如下图新建之后进入该应用，如下图点击新建规格，如下图填写信息后，点击确定后，进入依赖配置页面，如下图点击上图右上方的价格预算按钮，可以查看该配置的预算费用，如下图完成依赖配置后点击保存即可。回到 给应用的详情页面，导出上面新建的部署架构，如下图点击提交，可以把该部署规格提交给iotstage审核，审核通过后会得到相应的应用链接在设计中心页面上传上一步导出的规格，如下图应用链接即为上一步提交审核通过后的获得的应用链接，这个链接是后续资源开通时候一键自动部署的链接地址。如果我们没有把新建的规格提交审核，那么应用链接可以自行编写，只是不能在资源开通的时候一键部署应用。1.1.4 方案提交评审架构设计、配置清单设计完成后，设计中心页面点击右上角的提交审核按钮，然后在弹窗中选择审核负责人（项目经理角色），点击确定提交，如下图提交审核后，相应的负责人生成一条审核的待办事项。下一步：方案审核1.1.5 方案审核支持项目经理从方案审核待办进入到方案审核页面，待办事项如下图点击处理按钮后，进入到方案方案审核页面，如下图通过审核，方案的业务即全部完成。驳回至方案设计阶段，方案回到设计阶段，方案设计负责人生成方案设计待办事项。驳回至方案注册阶段，方案回到注册阶段，方案注册人生成方案注册的待办事项。1.1.6 方案详情用户进入方案管理页面，如下图点击方案名称即可进入到该方案的详情页。

现在网上讨论的有关物联网的咨询非常之多，但大部分都是介绍理论或者有关硬件，通讯相关的问题，比如物联网模块，物联网通讯协议MQTT、XMPP、NB_IOT等，个人认为这些只是物联网中一部分，而涉及到物联网的设备如何管理，用户如何管理，数据包如何解析，大数据如何展示等也是物联网模块中非常重要的部分，所以作者就根据自身工作中总结出来的建构在云端的物联网平台基本架构分享给大家，并基于此架构如何一步一步来开发一套物联网平台。物联网平台，应该是基于现在的互联网，通讯技术来建构，而不依赖与特定的硬件模块，用户可以基于自身的设备技术架构，简单轻松接入物联网。下图是物联网的核心架构：1. 四大核心模块在物联网中存在4大核心模块，那就是设备管理，用户管理，数据传输管理，数据管理，只有具备了这四大核心模块，才能认为是一个完整的物联网平台，而所有其他的功能模块都是基于此四大功能模块的延展。1.1 设备管理 设备类型管理：定义设备的类型，此功能一般由设备的制造商来定义，一种设备类型最重要的是关联到一套独有的数据解析方法，数据的存储方法，已经设备规格等数据，也只有设备的制造商才可以编辑有关设备类型的数据，而设备的使用者只能浏览设备类型的相关信息设备管理：设备管理定义设备相关信息，每个设备必须定义其设备类型，设备类型有使用者属性，设备在完成销售，并被使用者激活后设备就属于设备使用者了，这时候设备使用者对设备有完全的控制权，可以控制设备的哪些数据可以被制造商查看，可以被哪些用户查看等权限1.2 用户管理组织管理：在物联网平台中一个很重要的观念就是组织，所有的设备，用户，数据都是基于组织的管理的，设备制造商是一个组织，设备的使用者是一个组织，家庭都可以是一个组织。用户管理：用户是基于一个组织下的人员构成，每个组织下面都有管理员角色，管理员可以为其服务的组织添加不通的用户，并分配每个用户不同的权限。一个用户也可以属于多个不同的组织，并且扮演不同的组织。 用户组：一组用户，也是基于组织的用户组管理，同一用户组的用户拥有相同的权限权限管理：同样是基于组织的权限管理，主要是针对对象级别的权限细分，如设备的浏览权限，可以控制每个用户是否看到这个设备；设备数据浏览权限定义是否可以查看设备的运行数据1.3 数据传输管理1.31 基本格式数据传输管理，定义针对一类型设备的数据传输协议，基本格式是:每一个设备有厂商唯一的序列号，因为每个制造商有自己的编码格式，固此序列号没有固定格式。命令码，为此条数据的作用，比如是上传数据，或者服务器下发给设备的命令等，一般采用2位数字编码00~99数据，此部分是此条报文，所包含的数据部分，每个协议可以定义不同的解析方式，比如服务器在收到数据包后，会根据预先定义好的解析方式解析数据字段，并按照规则存储1.32 数据解析定义每种设备类型可以定义多条命令，每个命令都有自己不同的解析方式，组织的管理员可以为自己的设备类型定义解析方式，服务器接收到数据后，会自动根据预先定义的解析方式解析数据字段，设备开发者要根据在IOT平台定义的数据格式，自行开发自己设备的解析代码，数据字段都按照HEX方式收发。1.33 数据的存储存储要支持分布式架构，可以为每个设备定义不同的存储位置，在diego iot中数据存储使用mysql数据库，实现不同的设备存储在不同的mysql数据库中每条数据定义生命周期，在生命结束后，系统将自动删除1.4 数据管理 权限管理，数据的权限在物联网平台中是至关重要，数据属于谁是一个非常重要的概念，只有设备的拥有者才能定义数据可以给谁看；大数据，物联网数据本身就是海量的数据，我们可以借助一些开源的大数据平台来实现数据的可视化分析，只有经过分析的数据才是有价值的数据；数据的导出，用户可以导出数据到本地做分析；2.网络通讯现在所有的云端的物联网平台和设备之间的通讯，本质上都是建构在TCP/IP协议之上的，只是对数据包的再封装而已，基于此我们可以是用wifi，4g来实现设备和云平台的通讯，不过设备与设备之间的通讯，可以有wifi，Bluetooth，zigbee等，下面介绍几种常用的通讯架构2.1 基于移动3/4G通讯此架构是最简单的架构，设备就如同我们的手机，基于移动通讯来上网，其主要需要考虑如下几点：每个设备都需要一个SIM卡，可以到移动服务器商办理专门针对物联网的SIM卡；数据流量问题，这种架构完全是走数据流量，如果有视频数据，将会产生比较大的流量费用，这都是要考虑的；通讯质量问题，这完全依赖于移动服务商的网络覆盖状况，就如同我们手机一样，在有些环境下是没有信号的，也就没办法收发数据；2.2 基于wifi局域网此中架构，适合于所有的物联网设备都是运行在一个局部环境中，设备通过wifi或者有线连接到路由器，而由路由器统一连接的物联网服务器，就如同我们家中装一个wifi路由器上网一样的架构，需要注意的事项：1.局域网内的智能设备，是没有公网独立的ip的，只有一个局域网内的ip，带来的问题就是，设备可以直接给物联网服务器发送数据包，而物联网服务器是不能直接给设备发送数据包，就因为设备没有公网独立ip2.功耗问题，对于使用wifi接入的设备，最好不是电池供电，因为wifi的功耗比较大3.干扰问题，如果在大型的厂房部署这种架构，一定要考虑，厂房内是否有强干扰源，如电磁干扰，可以考虑采用工业级的无线路由器，一般抗干扰能力比较强2.3 基于蓝牙通讯一般的基于蓝牙的物联网，会考虑通过蓝牙网关来部署蓝牙由于其点对点的通讯方式，所以要考虑如下问题：1.蓝牙网关的容量问题，也就是一个蓝牙网关能接入几个蓝牙设备，这取决于蓝牙网关中使用了多少个蓝牙设备2.蓝牙的配对问题，蓝牙设备直接的通讯都首先配对才能通讯，如果实现自动配对，如果不能自动配对，大规模部署，将是一个很麻烦的事情还有一种场景是针对不需要一直在线的物联网设备，而只是在某种特殊需求的情况下，需要连上服务器，这中场景下，我们可以通过手机的蓝牙功能来让设备接入物联网蓝牙手环是这种架构的一种典型应用模式2.4 基于zigbeeZigBee也是一种流行的组网模式，zigbee本身设计是针对传感器之间的联网，具有非常强的低功耗能力。zigbee接入网络也依赖于zigbee网关，网关本身也是一个zigbee设备，zigbee设备是自组网的，在使用过程中注意的问题有数据量的问题，设备能力和功耗本身是自相矛盾的，由于ZigBee是超低功耗方案，固在通信能力上也是打折扣的，很适合一些传感器数据的采集，如温度湿度，但如果对大数据量的视频类的就不适用了这里主要介绍了，几种常用的物联网部署架构，至于物联网协议，这里就不多介绍，网上文章非常多。3.智能设备diego iot设计的初衷是让智能设备开发者摆脱对特殊模块的依赖，对于智能设备的开发，只要具备联网功能即可，没有特别多的要求————————————————原文链接：https://blog.csdn.net/ly_asmt/article/details/121125324

ADC项目开发流程介绍适用场景本文内容适用于基于ADC（低代码）平台开发的项目，为相关人员提供业务设计思路，尤其在项目组由多人组成的情况下（包括项目经理、设计师、开发者等），建议规范化运作项目。一、       项目开发全流程图为使流程更清晰，省略了各环节的评审及详细内容，如有更好的建议，欢迎提出。(以下流程适用与5人以内的项目，包含（业务需求方）、项目经理、架构设计、开发人员等)1.1       项目启动1.1.1      需求调研              正式开发前，项目经理应输出相关文档，调研详细需求并输出方案设计（PPT形式即可），此文档有助于向项目组人员（包含架构设计、开发者、第三方系统负责人等）传递项目信息。输出的《项目概要及计划安排》文档，包含整体项目背景、业务痛点、项目目标等。1.2       需求确认1.2.1      方案设计              整体业务设计及业务流设计，并确认使用的技术，确认多个系统间的调用关系。1.3       设计阶段1.3.1      原型设计            1. UI-页面原型设计:    页面是展现在人机交互的使用和看得到的界面。需要考虑的点：最终需要呈现哪些页面；页面需要具备的具体功能（信息呈现、流程活动、页面跳转等）；            2. 表结构设计：                 ”表结构设计“即“数据库E-R图”绘制，需要通过综合、归纳与抽象用户需求，形成一个具体的概念模型。E-R 图主要用于在项目团队内部，设计人员和业务方、开发人员进行沟通，确认                    需求信息的正确性和完整性。                 E-R图概念：即实体-联系图(Entity Relationship Diagram)，是指提供了表示实体、属性和联系的方法，用来描述现实世界的概念模型。            3. 业务流设计：用户视角：区分不同类型用户使用视角；开发视角：设计不同模块间（页面/表）数据传递方式及内容。如涉及到第三方系统互通，需要明确互通方式及API数据格式。1.3.2      详细设计             在设计UI页面、表时，注意各个模块间解耦，增强后续可迭代性和可扩展性。             1. UI-页面详细设计：（工具选择：简易版-PPT ，高阶版：XD、Axure工具），UI设计，需要从用户视角触发，注重使用者的操作习惯和角色。                 a.设计总页面，菜单分类，各个菜单之间的关系；                 b. 每个页面中显示的内容，如：文字显示/输入框、按钮的名称，对应的触发动作（如：点击按钮时，需要保存信息）。             2.表结构设计（模型）：(工具选择：简易版-excel，高阶版：Edraw、MindMaster等工具)                 a.明确各表名称，主键，属性，属性类型等；                 b.明确多个表之间的映射关系。             3.业务流设计：(工具选择：简易版-PPT，高阶版：Edraw、MindMaster等工具)                       a.页面与表之间关系 ；                 b.页面与第三方系统之间的互通。1.4       开发阶段1.4.1      分工    多人开发的项目，负责的模块尽量解耦，避免多人操作同一个页面或者代码。为便于沟通，建议项目组成员尽量在一起办公。如：开发者A：负责建模，负责菜单中“首页”、“新增报告”、“浏览报告”；开发者B：负责菜单中“日志管理”、“用户管理”；开发者C：负责API互通部分。1.4.2      开发过程中注意事项代码需要些注释，表明是谁，什么时间，加了什么功能的代码；在修改模型关键字段时，告知团队其他成员。（如字段被其他页面或者代码使用时，会被影响）；谨慎删除模型中的属性、页面、代码；如需修改原有代码或者逻辑，注意进行备份；如掌握的新技能，建议在做笔记，善于经验总结。1.5       测试       开发者要自行测试后，各开发者之间要交叉验证，保证验证全面。准备多个样例数据进行验证。1.6       上线       建议上线的环境与开发的环境隔离，保证开发与上线运行并行。上线前建议先试运行一段时间，限制使用范围，待无明显BUG后，再正式上线。二、       各类文档及过程产物序号文档输出责任人阶段备注1项目概要及计划安排项目经理项目启动 2方案设计项目经理概要需求 3原型设计架构设计设计 4界面设计架构设计设计 5表结构设计架构设计设计 6项目计划表项目经理/架构设计开发 7程序使用手册/上线 8项目总结/上线后  

项目背景:用户通过域名访问vip, nginx做为负载均衡为后端应用分发请求, 后端应用为dubbo服务,存储分为redis和mysql. redis做为持久会存储数据库,支持前端业力. 并且通过mq同步数据到mysql,供后端使用. 同时后台写mysql也要通过mq同步到redis.目前后端服务qps最高可以达到5万,本次架构设计在不重构的情况下短期内最快的方法达到目标10万qps.架构方案:一，现有idc架构可支撑5万qps。这是经过一年考验下来的，可做为保底的；如果应用全部上云，需要从0开始重新验证能否达到现有5万qps，再去验证能否达到10万qps，时间等未知风验很大；  二，10万qps目标，建议用简单粗暴的方式，直接把idc应用层架构复制一套上云；不建议在现有架构上继续调优，现在架构如果不重构，可能很难找到问题；与其这样不如把人力时间用到另一个方向，比如数据中心；   三，由idc+公有云两套系统构成混合云模式，数据统一使用idc的redis和mysql，公有云与idc 的数据库连接建立专线；混合云的方式可以检测公有云的实际性能，也能为将来全部迁移公有云提供真实参考；   四，平时比赛，使用idc架构完全可以支撑，公有云留少量机器和用户请求预热，重要比赛，临时增加云资源扛突发，服务器成本节约，扩展性也灵活；   五，公有云都有出现过大规模事故,造成全站不能访问的情况,为了保险，我们依然要保留idc的服务，所以混合云也许是最适合的；      技术难点：   一，如何将用户请求分流到 idc和公有云两套应用   1，域名解析两条A记录，分别指向idc和公有云两个vip，通过dns平均分配用户请求   2，idc架构在nginx前端增加四层负载均衡（lvs,ha_porxy），由四层负载均衡将用户请求转发给idc的nginx和公有云的负载均衡，lvs与公有云通信通过专线；   二，前端应用入口放大，后端数据中心，需要扩容   1，redis使用多主多从，redis3.0 还是用 代理（predixy,codis）；   2，业务拆分，组建更多的一主多从；      具体实施：   1，双系统流量分发配置lvs即可，本赛季最好能用上几轮，演练资源增减，熟悉流程，检测可行性；   2，redis数据中心需要大量的测试，选型，可做重点研究（这也是目前急需解决的单点）；

开发类项目全流程本文内容适用于基于ADC（低代码）平台开发的项目，为相关人员提供业务设计思路，如项目组由多人组成的情况下（包括项目经理、设计师、开发者等），建议规范化运作项目。一、       项目开发流程为使流程更清晰，省略了各环节的评审及详细内容，如有更好的建议，欢迎提出。1.1       项目启动1.1.1      需求调研正式开发前，项目经理应输出相关文档，调研详细需求并输出方案设计（PPT形式即可），此文档有助于向项目组人员（包含架构设计、开发者、第三方系统负责人等）传递项目信息文档输出：“项目概要及计划安排”，包含整体项目背景、业务痛点、项目目标等。1.2       概要需求1.2.1      方案设计整体业务设计及业务流设计，并确认使用的技术，确认多个系统间的调用关系。1.3       设计阶段1.3.1      原型设计UI-页面原型设计；页面是展现在人机交互的使用和看得到的界面。需要考虑的点：最终需要呈现哪些页面；页面需要具备的具体功能（信息呈现、流程活动、页面跳转等）；      2. 表设计；      3. 业务流设计：用户视角：区分不同类型用户使用视角。开发视角：设计不同模块间（页面/表）数据传递方式及内容。如涉及到第三方系统互通，需要明确互通方式及API数据格式1.3.2      详细设计在设计UI页面、表时，注意各个模块间解耦，增强后续可迭代性和可扩展性。UI-页面详细设计；（工具选择：简易版-PPT ，高阶版：XD、Axure工具）UI设计，需要从用户视角触发，注重使用者的操作习惯和角色。设计总页面，菜单分类，各个菜单之间的关系。每个页面中显示的内容，如：文字显示/输入框按钮的名称，对应的触发动作（如：点击按钮时，需要保存信息）    2. 表设计（模型）：明确各表名称，主键，属性，属性类型等明确多个表之间的映射关系    3. 业务流设计：页面与表之间关系页面与第三方系统之间的互通1.4       开发阶段1.4.1      分工多人开发的项目，负责的模块尽量解耦，避免多人操作同一个页面或者代码。为便于沟通，建议项目组成员尽量在一起办公。如：开发者A：负责建模，负责菜单中“首页”、“新增报告”、“浏览报告”开发者B：负责菜单中“日志管理”、“用户管理”开发者C：负责API互通部分1.4.2      开发过程中注意事项代码需要些注释，表明是谁，什么时间，加了什么功能的代码。在修改模型关键字段时，告知团队其他成员。（如字段被其他页面或者代码使用时，会被影响）。谨慎删除模型中的属性、页面、代码。如需修改原有代码或者逻辑，注意进行备份。如掌握的新技能，建议在做笔记，善于经验总结。1.5       测试开发者要自行测试后，各开发者之间要交叉验证，保证验证全面。准备多个样例数据进行验证。1.6       上线建议上线的环境与开发的环境隔离，保证开发与上线运行并行。上线前建议先试运行一段时间，限制使用范围，待无明显BUG后，再正式上线。二、       各类文档及过程产物序号文档输出责任人阶段备注1项目概要及计划安排项目经理项目启动 2方案设计项目经理概要需求 3原型设计架构设计设计 4界面设计架构设计设计 5表结构设计架构设计设计 6项目计划表项目经理/架构设计开发 7程序使用手册/上线 8项目总结/上线后  

本文内容适用于基于ADC（低代码）平台开发的项目，为相关人员提供业务设计思路，如项目组由多人组成的情况下（包括项目经理、设计师、开发者等），建议规范化运作项目。一、      项目开发流程      为使流程更清晰，省略了各环节的评审及详细内容，如有更好的建议，欢迎提出。1.1      项目启动1.1.1     需求调研正式开发前，项目经理应输出相关文档，调研详细需求并输出方案设计（PPT形式即可），此文档有助于向项目组人员（包含架构设计、开发者、第三方系统负责人等）传递项目信息文档输出：“项目概要及计划安排”，包含整体项目背景、业务痛点、项目目标等。1.2      概要需求1.2.1     方案设计整体业务设计及业务流设计，并确认使用的技术，确认多个系统间的调用关系。1.3      设计阶段1.3.1     原型设计1、 UI-页面原型设计；页面是展现在人机交互的使用和看得到的界面。需要考虑的点：最终需要呈现哪些页面；页面需要具备的具体功能（信息呈现、流程活动、页面跳转等）；2、 表设计；3、 业务流设计：a)     用户视角：区分不同类型用户使用视角。b)     开发视角：设计不同模块间（页面/表）数据传递方式及内容。如涉及到第三方系统互通，需要明确互通方式及API数据格式1.3.2     详细设计在设计UI页面、表时，注意各个模块间解耦，增强后续可迭代性和可扩展性。1、  UI-页面详细设计；（工具选择：简易版-PPT ，高阶版：XD、Axure工具）UI设计，需要从用户视角触发，注重使用者的操作习惯和角色。a)     设计总页面，菜单分类，各个菜单之间的关系。b)     每个页面中显示的内容，如：                        i.         文字显示/输入框                       ii.         按钮的名称，对应的触发动作（如：点击按钮时，需要保存信息）2、  表设计（模型）：a)     明确各表名称，主键，属性，属性类型等b)     明确多个表之间的映射关系3、  业务流设计：a)     页面与表之间关系b)     页面与第三方系统之间的互通1.4      开发阶段1.4.1     分工多人开发的项目，负责的模块尽量解耦，避免多人操作同一个页面或者代码。为便于沟通，建议项目组成员尽量在一起办公。如：Ø  开发者A：负责建模，负责菜单中“首页”、“新增报告”、“浏览报告”Ø  开发者B：负责菜单中“日志管理”、“用户管理”Ø  开发者C：负责API互通部分1.4.2     开发过程中1、  注意事项a)     代码需要些注释，表明是谁，什么时间，加了什么功能的代码。b)     在修改模型关键字段时，告知团队其他成员。（如字段被其他页面或者代码使用时，会被影响）。c)     谨慎删除模型中的属性、页面、代码。d)     如需修改原有代码或者逻辑，注意进行备份。e)     如掌握的新技能，建议在做笔记，善于经验总结。1.5      测试开发者要自行测试后，各开发者之间要交叉验证，保证验证全面。准备多个样例数据进行验证。1.6      上线建议上线的环境与开发的环境隔离，保证开发与上线运行并行。上线前建议先试运行一段时间，限制使用范围，待无明显BUG后，再正式上线。二、      各类文档及过程产物序号文档输出责任人阶段备注1项目概要及计划安排项目经理项目启动 2方案设计项目经理概要需求 3原型设计架构设计设计 4界面设计架构设计设计 5表结构设计架构设计设计 6项目计划表项目经理/架构设计开发 7程序使用手册/上线 8项目总结/上线后  

我们还可能出于统计原因来选择深度模型。任何时候，当我们选择一个特定的机器学习算法时，我们隐含地陈述了一些先验，这些先验是关于算法应该学得什么样的函数的。选择深度模型默许了一个非常普遍的信念，那就是我们想要学得的函数应该涉及几个更加简单的函数的组合。这可以从表示学习的观点来解释，我们相信学习的问题包含发现一组潜在的变差因素，它们可以根据其他更简单的潜在的变差因素来描述。或者，我们可以将深度结构的使用解释为另一种信念，那就是我们想要学得的函数是包含多个步骤的计算机程序，其中每个步骤使用前一步骤的输出。这些中间输出不一定是变差因素，而是可以类似于网络用来组织其内部处理的计数器或指针。根据经验，更深的模型似乎确实在广泛的任务中泛化得更好 (Bengio et al., 2007b; Erhan et al., 2009; Bengio, 2009; Mesnil et al., 2011; Ciresan et al., 2012; Krizhevsky et al., 2012a; Sermanet et al., 2013; Farabet et al., 2013; Couprie et al., 2013; Kahou et al., 2013; Goodfellow et al., 2014d; Szegedy et al., 2014a)。展示了一些实验结果的例子。这表明使用深层架构确实在模型学习的函数空间上表示了一个有用的先验。

现在网上讨论的有关物联网的帖子非常之多，但大部分都是介绍理论或者有关硬件，通讯相关的问题，比如物联网模块，物联网通讯协议MQTT、XMPP、NB_IOT等，个人认为这些只是物联网中一部分，而涉及到物联网的设备如何管理，用户如何管理，数据包如何解析，大数据如何展示等也是物联网模块中非常重要的部分，所以作者就根据自身工作中总结出来的建构在云端的物联网平台基本架构分享给大家，并基于此架构如何一步一步来开发一套物联网平台。物联网平台，应该是基于现在的互联网，通讯技术来建构，而不依赖与特定的硬件模块，用户可以基于自身的设备技术架构，简单轻松接入物联网。下图是物联网的核心架构：1. 四大核心模块在物联网中存在4大核心模块，那就是设备管理，用户管理，数据传输管理，数据管理，只有具备了这四大核心模块，才能认为是一个完整的物联网平台，而所有其他的功能模块都是基于此四大功能模块的延展。1.1 设备管理设备类型管理：定义设备的类型，此功能一般由设备的制造商来定义，一种设备类型最重要的是关联到一套独有的数据解析方法，数据的存储方法，已经设备规格等数据，也只有设备的制造商才可以编辑有关设备类型的数据，而设备的使用者只能浏览设备类型的相关信息设备管理：设备管理定义设备相关信息，每个设备必须定义其设备类型，设备类型有使用者属性，设备在完成销售，并被使用者激活后设备就属于设备使用者了，这时候设备使用者对设备有完全的控制权，可以控制设备的哪些数据可以被制造商查看，可以被哪些用户查看等权限1.2 用户管理组织管理：在物联网平台中一个很重要的观念就是组织，所有的设备，用户，数据都是基于组织的管理的，设备制造商是一个组织，设备的使用者是一个组织，家庭都可以是一个组织。用户管理：用户是基于一个组织下的人员构成，每个组织下面都有管理员角色，管理员可以为其服务的组织添加不通的用户，并分配每个用户不同的权限。一个用户也可以属于多个不同的组织，并且扮演不同的组织用户组：一组用户，也是基于组织的用户组管理，同一用户组的用户拥有相同的权限权限管理：同样是基于组织的权限管理，主要是针对对象级别的权限细分，如设备的浏览权限，可以控制每个用户是否看到这个设备；设备数据浏览权限定义是否可以查看设备的运行数据1.3 数据传输管理1.31 基本格式数据传输管理，定义针对一类型设备的数据传输协议，基本格式是:每一个设备有厂商唯一的序列号，因为每个制造商有自己的编码格式，固此序列号没有固定格式。命令码，为此条数据的作用，比如是上传数据，或者服务器下发给设备的命令等，一般采用2位数字编码00~99数据，此部分是此条报文，所包含的数据部分，每个协议可以定义不同的解析方式，比如服务器在收到数据包后，会根据预先定义好的解析方式解析数据字段，并按照规则存储1.32 数据解析定义每种设备类型可以定义多条命令，每个命令都有自己不同的解析方式，组织的管理员可以为自己的设备类型定义解析方式服务器接收到数据后，会自动根据预先定义的解析方式解析数据字段设备开发者要根据在IOT平台定义的数据格式，自行开发自己设备的解析代码数据字段都按照HEX方式收发1.33 数据的存储存储要支持分布式架构，可以为每个设备定义不同的存储位置，在diego iot中数据存储使用mysql数据库，实现不同的设备存储在不同的mysql数据库中?每条数据定义生命周期，在生命结束后，系统将自动删除1.4 数据管理权限管理，数据的权限在物联网平台中是至关重要，数据属于谁是一个非常重要的概念，只有设备的拥有者才能定义数据可以给谁看大数据，物联网数据本身就是海量的数据，我们可以借助一些开源的大数据平台来实现数据的可视化分析，只有经过分析的数据才是有价值的数据数据的导出，用户可以导出数据到本地做分析2.网络通讯现在所有的云端的物联网平台和设备之间的通讯，本质上都是建构在TCP/IP协议之上的，只是对数据包的再封装而已，基于此我们可以是用wifi，4g来实现设备和云平台的通讯，不过设备与设备之间的通讯，可以有wifi，Bluetooth，zigbee等，下面介绍几种常用的通讯架构2.1 基于移动3/4G通讯此架构是最简单的架构，设备就如同我们的手机，基于移动通讯来上网，其主要需要考虑如下几点每个设备都需要一个SIM卡，可以到移动服务器商办理专门针对物联网的SIM卡数据流量问题，这种架构完全是走数据流量，如果有视频数据，将会产生比较大的流量费用，这都是要考虑的通讯质量问题，这完全依赖于移动服务商的网络覆盖状况，就如同我们手机一样，在有些环境下是没有信号的，也就没办法收发数据2.2 基于wifi局域网此中架构，适合于所有的物联网设备都是运行在一个局部环境中，设备通过wifi或者有线连接到路由器，而由路由器统一连接的物联网服务器，就如同我们家中装一个wifi路由器上网一样的架构，需要注意的事项：局域网内的智能设备，是没有公网独立的ip的，只有一个局域网内的ip，带来的问题就是，设备可以直接给物联网服务器发送数据包，而物联网服务器是不能直接给设备发送数据包，就因为设备没有公网独立ip功耗问题，对于使用wifi接入的设备，最好不是电池供电，因为wifi的功耗比较大干扰问题，如果在大型的厂房部署这种架构，一定要考虑，厂房内是否有强干扰源，如电磁干扰，可以考虑采用工业级的无线路由器，一般抗干扰能力比较强2.3 基于蓝牙通讯一般的基于蓝牙的物联网，会考虑通过蓝牙网关来部署蓝牙由于其点对点的通讯方式，所以要考虑如下问题：蓝牙网关的容量问题，也就是一个蓝牙网关能接入几个蓝牙设备，这取决于蓝牙网关中使用了多少个蓝牙设备蓝牙的配对问题，蓝牙设备直接的通讯都首先配对才能通讯，如果实现自动配对，如果不能自动配对，大规模部署，将是一个很麻烦的事情还有一种场景是针对不需要一直在线的物联网设备，而只是在某种特殊需求的情况下，需要连上服务器，这中场景下，我们可以通过手机的蓝牙功能来让设备接入物联网蓝牙手环是这种架构的一种典型应用模式2.4 基于zigbeeZigBee也是一种流行的组网模式，zigbee本身设计是针对传感器之间的联网，具有非常强的低功耗能力zigbee接入网络也依赖于zigbee网关，网关本身也是一个zigbee设备，zigbee设备是自组网的，在使用过程中注意的问题有数据量的问题，设备能力和功耗本身是自相矛盾的，由于ZigBee是超低功耗方案，固在通信能力上也是打折扣的，很适合一些传感器数据的采集，如温度湿度，但如果对大数据量的视频类的就不适用了这里主要介绍了，几种常用的物联网部署架构，至于物联网协议，这里就不多介绍，网上文章非常多。3.智能设备diego iot设计的初衷是让智能设备开发者摆脱对特殊模块的依赖，对于智能设备的开发，只要具备联网功能即可，没有特别多的要求。原文链接：https://blog.csdn.net/kymdidicom/article/details/114697654?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522162510653816780269812639%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=162510653816780269812639&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_v2~rank_v29-22-114697654.pc_search_result_before_js&utm_term=%E7%89%A9%E8%81%94%E7%BD%91lot&spm=1018.2226.3001.4187

开源数据库架构设计原则01. 技术选型选择成熟的平台和技术，同时是最熟悉的，能做到极致的，用好不用坏，用熟不用生。目前业界的MySQL主流分支版本有Oracle官方版本的MySQL、Percona Server、MariaDB。02. 高可用选择高可用解决方案探讨的本质上是低宕机时间解决方案，可以理解成高可用的反面是不可用，绝大部分情况下数据库宕机才会导致数据库不可用。随着技术发展，开源数据库方面很多高可用组件（主从复制、半同步、MGR、MHA、Galera Cluster）,对应场景，只有适合的，没有万能的，需要理解每个高可用优缺点。03. 表设计表设计方面目前一致坚持和提倡的原则：单表数据量所有表都需要添加注释，单表数据量建议控制在 3000 万以内不保存大字段数据不在数据库中存储图片、文件等大数据表使用规范拆分大字段和访问频率低的字段，分离冷热数据单表字段数控制在 20 个以内索引规范1.单张表中索引数量不超过 5 个2.单个索引中的字段数不超过 5 个3.INNODB 主键推荐使用自增列，主键不应该被修改，字符串不应该做主键，如果不指定主键，INNODB 会使用唯一且非空值索引代替4.如果是复合索引，区分最大的字段放在索引前面5. 避免冗余或重复索引：合理创建联合索引（避免冗余）6. 不在低基数列上建立索引，例如‘性别'7. 不在索引列进行数学运算和函数运算字符集utf8mb4(偏生字，表情符)04. 优化原则                    05. 复制方式MySQL复制方式提供异步方式、半同步方式、全局事务强一致性、binglog同步。需要不同业务系统间 或 两个数据库间进行同步。异步方式可以防止故障和效率问题的蔓延，扩大化；但强一致性会更复杂，并发、事务大小都有求限制06. 分离原则区分核心的业务，重要业务，渠道，内部业务的业务系统，对不同的系统设置不同的架构。为核心业务设置 最佳为分库，多活 专用高速公路，其他业务可以做读写分离，缓存。07. 扩展性对于系统来说扩展性很重要，尽量做到水平扩展。避免过度依赖纵向扩展，同时具备纵向，横向扩展的能力，例如无状态应用应该多套负载均衡多活部署，数据库分库架构。08. 读写分离读多写少场景（10%写 90%读）复制存在延迟，业务对延迟不敏感的实现方式：                    1. 通过应用代码配置读写分离，                    2. 通过中间代理方式路由只读库                     3. 业务和数据库为一个单位09. 分库分表当表中数据记录的数量超过3000万条，再好的索引也已经不能提高数据查询的速度，这时需要将表拆分成更多的小表，增加性能，增加弹性，避免发生垮库进行操作。引入中间价要考虑性能代价,聚合需求。分库原则尽量在app 上层进行分库，就是流量。分多少合适：可用性和性能满足TPS。路由：写入配置文件 或则 插表 或则 zookeeper。10. 归档原则历史数据定期进行归档 或则 移到其他大数据平台。能让轻量级数据库更多缓存有用的数据。在MySQL分区表里 注意要避免分区锁，只能写读的场景。11. 连接池的要求长链接，自动重链，延时和异常记录， 弹性链接，检测满，异常告警，进阶要求是记录所有访问情况，可以扩展出很多能力。应用和数据库连接池设置，数据库允许的连接数设置，常见问题。A ）应用的数据库连接池设置偏小，一旦数据库相应慢（新上线应用，缺少索引 等）则应。用排队严重，甚至雪崩，而遗憾的是数据库能力还远为用尽。B ）不具备失效及时发现和重新链接数据库能力。C ）隔离级别设置：RR 和 RC下不同的表现。12. 应用解耦通过应用访问数据库而不是直接访问，重要业务不能依赖低保障级别的系统，应用层重要业务和普通业务解耦，关键业务要独立。13. 组件失效免疫能力单一应用，单一硬件，甚至单一基础设施，单一站点容灾，业务影响，故障恢复能力，要季度级别进行演练。14. 关键词组件减负特别是数据库访问,数据库成本最高，扩展性最难，可用性保障最难，恢复难度和时间最大。减负：能不用就不用，使用最简单，成本最低的语句，避免大事务，慎用两阶段事务。15. 灰度数据库减少发布时变更数据库对全局的影响,只有应用程序灰度是不够的，还要有专门的灰度数据库。在分库、读写分离架构下，一套含数据库的完整应用架构，变的很自然。所为灰度环境就是生产环境，生产数据，所影响的也是生产环境，只是范围比测试环境更广，更真实。其实就是小范围的生产环境。类似于游戏内测。16. 高仿真架构体系建立高仿真架构体系数据库，操作系统升级：应用是否适应，性能会变好， 还是变坏应用上线发布，系统变更（列如换平台），提前判断业务影响和性能瓶颈应对突发交易量，例如双十一，性能极限在哪里，瓶颈在哪里。17. 容灾保障高可用是运维核心要求，容灾是最后屏障例如 双活比单活好，MGR比复制架构好，重要系统要做好高可用，容灾建设。18. 多中心建设冗余是基础，多中心建设是为了提升容灾能力和扩展能力，并保障业务。19. 应用和数据库是一个整体应用和运维人员一起，解决应用解耦，数据库解耦，追账补数，业务监控，应用路由，故障切换等。可用性，效率，故障恢复等方面都要一起参与。20. 性能提升开源数据库使用应该合理且有效的结合周边的其他类型数据库，做到性能最大化。比如：Redis、MongoDB、ES、ClickHouse等。总结1. 最适合的架构是结合软件特性和业务场景，又能取得成本收益平衡；2. 大数据情况下可以是利用读写分离、分库分表，但要选择合适的；3. 不适合分库的应该考虑竭尽所能把核心库做小，然后通过垂直扩展来扩容；4. 用尽各种技术， 高可用 和 容灾手段保证其可用。

1、什么是架构和架构本质在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。我们主要针对互联网服server系统（类似网站）来定义架构：架构是系统的骨架，支撑和链接各个部分，包括组件、连接件、约束规范，以及指导这些内容设计与演化的原理。组件：类似应用服务，独立模块、数据库、nginx等等、连接件：分布式调用、进程间调用、调用使用http协议还是tcp协议、组件之间的交互关系、约束规范： 定规则做限制：例如设计原则、编码规范等等。是系统性地思考，权衡利弊之后在现有资源约束下的“最合理决策”，并由它来指导团队中的每个人思想层面上的一致。即架构=组件+交互。这类似建筑设计规划，城市总体规划等，其实就是架构，只是应用的场景不同。盖一座小房子，可以拍脑袋干起来，但是当你要盖一座大楼，如果没有一个建筑设计规划，可以想象搭理最后是什么样？架构的本质就是对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。那什么样的系统要考虑做架构设计?1. 需求相对复杂.2. 非功能性需求在整个系统占据重要位置.3. 系统生命周期长,有扩展性需求.4.系统基于组件或者集成的需要.5.业务流程再造的需要. 2、架构分类架构可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构,.业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。熟悉业务，形成业务架构，根据业务架构，做出相应的应用架构，最后技术架构落地实施。如何针对当前需求，选择合适的应用架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。一、业务架构（俯视架构）：包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。 合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。看看京东业务架构（网上分享图）：二、应用架构（剖面架构，也叫逻辑架构图）：硬件到应用的抽象，包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。类似：应用架构：应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。应用架构图关键有2点：1、职责划分: 明确应用（各个逻辑模块或者子系统）边界1）逻辑分层2）子系统、模块定义。3）关键类。2、职责之间的协作：1）接口协议：应用对外输出的接口。2）协作关系：应用之间的调用关系。应用分层有两种方式：一种是水平分（横向），按照功能处理顺序划分应用，比如把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。另一种是垂直分（纵向），按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。应用的合反映应用之间如何协作，共同完成复杂的业务case，主要体现在应用之间的通讯机制和数据格式，通讯机制可以是同步调用/异步消息/共享DB访问等，数据格式可以是文本/XML/JSON/二进制等。应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分降低了业务复杂度，系统更有序，合增加了技术复杂度，系统更无序。应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。三、代码架构（也叫开发架构）：子系统代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。代码架构主要定义：一、代码单元:1、配置设计2、框架、类库。二、代码单元组织：1、编码规范，编码的惯例。2、项目模块划分3、顶层文件结构设计，比如mvc设计。4、依赖关系四、技术架构，也可以叫系统架构技术架构：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm等），这些运行组件之间的关系，以及部署到硬件的策略。技术架构主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这也是架构设计工作中最为困难的工作。五、部署拓扑架构图（实际物理架构图）：拓扑架构，包括架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是所有架构的基础。这个图主要是运维工程师主要关注的对象。3、应用架构架构演进路程：->初始阶段：LAMP,部署在一台服务器->应用服务器和数据服务器分离->使用缓存改善性能->使用集群改善并发->数据库地读写分离->使用反向代理和cdn加速->使用分布式文件和分布式数据库->业务拆分->分布式服务业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构需要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。企业一开始业务比较简单，比如进销存，此时面向内部用户，提供简单的信息管理系统（MIS），支持数据增删改查即可，单体应用可以满足要求。随着业务深入，进销存每块业务都变复杂，同时新增客户关系管理，以更好支持营销，业务的深度和广度都增加，这时需要对系统按照业务拆分，变成一个分布式系统。更进一步，企业转向互联网+战略，拓展在线交易，线上系统和内部系统业务类似，没必要重做一套，此时把内部系统的逻辑做服务化改造，同时供线上线下系统使用，变成一个简单的SOA架构。紧接着业务模式越来越复杂，订单、商品、库存、价格每块玩法都很深入，比如价格区分会员等级，访问渠道（无线还是PC），销售方式（团购还是普通）等，还有大量的价格促销，这些规则很复杂，容易相互冲突，需要把分散到各个业务的价格逻辑进行统一管理，以基础价格服务的方式透明地提供给上层应用，变成一个微内核的SOA架构。同时不管是企业内部用户，还是外部顾客所需要的功能，都由很多细分的应用提供支持，需要提供portal，集成相关应用，为不同用户提供统一视图，顶层变成一个AOA的架构（application orientated architecture）。4、衡量架构的合理性架构为业务服务，没有最优的架构，只有最合适的架构， 架构始终以高效，稳定，安全为目标来衡量其合理性。一、稳定性。指标：1. 高可用：要尽可能的提高软件的可用性，我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。二、高效指标：1. 文档化：不管是整体还是部分的整个生命周期内都必须做好文档化，变动的来源包括但不限于BUG，需求。2. 可扩展：软件的设计秉承着低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代，并且支持在适时对架构做出重构。3. 高复用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。三、安全指标1. 安全：组织的运作过程中产生的数据都是具有商业价值的，保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段5、常见架构误区误区1——架构专门由架构师来做，业务开发人员无需关注：架构的再好，最终还是需要代码来落地，并且组织越大这个落地的难度越大。不单单是系统架构，每个解决方案每个项目也由自己的架构，如分层、设计模式等。如果每一块砖瓦不够坚固，那么整个系统还是会由崩塌的风险。所谓“千里之堤，溃于蚁穴”。误区2——架构师确定了架构蓝图之后任务就结束了：架构不是“空中楼阁”，最终还是要落地的，但是架构师完全不去深入到第一线怎么知道“地”在哪？怎么才能落的稳稳当当。误区3——不做出完美的架构设计不开工：世上没有最好架构，只有最合适的架构。我们需要的不是一下子造出一辆汽车，而是从单轮车 --> 自行车 --> 摩托车，最后再到汽车。想象一下2年后才能造出的产品，当初市场还存在吗？6、架构知识体系架构演进初始阶段：LAMP,部署在一台服务器应用服务器和数据服务器分离使用缓存改善性能使用集群改善并发数据库地读写分离使用反向代理和cdn加速使用分布式文件和分布式数据库业务拆分分布式服务架构模式分层：横向分层：应用层，服务层，数据层分割：纵向分割：拆分功能和服务分布式分布式应用和服务分布式静态资源分布式数据和存储分布式计算集群：提高并发和可用性缓存：优化系统性能cdn方向代理访问资源本地缓存分布式缓存异步：降低系统的耦合性提供系统的可用性加快响应速度冗余：冷备和热备，保证系统的可用性自动化：发布，测试，部署，监控，报警，失效转移，故障恢复安全：架构核心要素高性能：网站的灵魂性能测试前端优化应用优化数据库优化可用性：保证服务器不宕机，一般通过冗余部署备份服务器来完成负载均衡数据备份自动发布灰度发布监控报警伸缩性：建集群，是否快速应对大规模增长的流量，容易添加新的机器集群负载均衡缓存负载均衡可扩展性：主要关注功能需求，应对业务的扩展，快速响应业务的变化。是否做法开闭原则，系统耦合依赖分布式消息服务化安全性：网站的各种攻击，各种漏洞是否堵住，架构是否可以做到限流作用，防止ddos攻击。xss攻击sql注入csr攻击web防火墙漏洞安全漏洞ssl7、架构书籍推荐1. 《大型网站技术架构：核心原理与案例分析》这是比较早，比较系统介绍大型网站技术架构的书，通俗易懂又充满智慧，即便你之前完全没接触过网站开发，通读前几章，也能快速获取到常见的网站技术架构及其应用场景。非常赞。2. 《亿级流量网站架构核心技术》相比《大型网站技术架构》的高屋建瓴，开涛的这本《亿级流量网站架构核心技术》则落实到细节，网站架构中常见的各种技术，比如缓存、队列、线程池、代理……，统统都讲到了，而且配有核心代码。甚至连 Nginx 的配置都有！如果你想在实现大流量网站时找参考技术和代码，这本书最合适啦。3. 《架构即未来》这是一本“神书”啦，超越具体技术层面，着重剖析架构问题的根源，帮助我们弄清楚应该以何种方式管理、领导、组织和配置团队。4. 《分布式服务架构：原理、设计与实战》这本书全面介绍了分布式服务架构的原理与设计，并结合作者在实施微服务架构过程中的实践经验，总结了保障线上服务健康、可靠的最佳方案，是一本架构级、实战型的重量级著作。5. 《聊聊架构》这算是架构方面的一本神书了，从架构的原初谈起，从业务的拆分谈起，谈到架构的目的，架构师的角色，架构师如何将架构落地……强烈推荐。不过，对于没有架构实践经验的小伙伴来讲，可能会觉得这本书比较虚，概念多，实战少。但如果你有过一两个项目的架构经验，就会深深认同书中追本溯源探讨的架构理念。6. 《软件架构师的12项修炼》大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到，缺乏的知识可以通过决定改变的努力来弥补。