我们还可能出于统计原因来选择深度模型。任何时候，当我们选择一个特定的机器学习算法时，我们隐含地陈述了一些先验，这些先验是关于算法应该学得什么样的函数的。选择深度模型默许了一个非常普遍的信念，那就是我们想要学得的函数应该涉及几个更加简单的函数的组合。这可以从表示学习的观点来解释，我们相信学习的问题包含发现一组潜在的变差因素，它们可以根据其他更简单的潜在的变差因素来描述。或者，我们可以将深度结构的使用解释为另一种信念，那就是我们想要学得的函数是包含多个步骤的计算机程序，其中每个步骤使用前一步骤的输出。这些中间输出不一定是变差因素，而是可以类似于网络用来组织其内部处理的计数器或指针。根据经验，更深的模型似乎确实在广泛的任务中泛化得更好 (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项修炼》大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到，缺乏的知识可以通过决定改变的努力来弥补。

# Cassandra 高可用架构设计 ## 简单单体应用架构 最简单的可以保证ACID原则的设计方式是实现一个包含所有功能的单体应用架构。因为被请求的节点中没有协调（coordinate）节点，执行所有系统规则的任务相对都比较简单。提升这种架构的可用性典型的操作就是升级硬件层，例如RAID磁盘矩阵，多网卡接口，热插拔驱动。然而，事实是即使最健壮的数据库服务也会单点故障问题。这就意味着如果服务器宕机，应用马上就变得不可用。这种架构如下图：  一种通用的扩容单体应用架构的方式是把存储层放在一个分片组件（shared component），例如存储区域网络(storage area network SAN)， 或者 NAS(Network Attached Storage:网络附属存储)。这些设备通常非常强大，具有海量磁盘和高速网络接口。 在上图的修改中显示，该图描绘了使用单个NAS的两个数据库服务器。  你将会注意到，这种架构增加了系统整体的请求处理能力，但只是简单的将单点故障从数据库服务层转移到存储层。最终，没有从根本上提升数据库的可用性。 ## 扩容一致性 – 主从架构模型 随着分布式系统变得越来越普遍，对更高容量的分布式数据库的需求也在增长。许多分布式数据库仍然想要保证ACID（或者在某些情况下只保证数据一致性，这点在分布式环境中是最困难的），从而产生了master-salve主从架构. 这种架构下，可能会有许多服务器处理请求，但是为了保证数据的一致性状态，只有一个服务器可以真实的执行写请求。这样避免了在并发写场景下同样的数据被路由到不同的节点进行修改操作。下面的图展示了最基础的情况：  然而，我们还是没有解决可用性的问题，因为数据库主节点(master)的宕机会导致应用的停服。这也就是说主节点不能很好的扩容，因为写请求只路由到一个单机节点上。 ### 使用分片来扩容主节点 有另外一种可以提升主从架构写入吞吐量的技术叫做分片(sharding)，在这种方式下，数据根据keys值不同被划分到不同分组，一个或者多个master可以拥有已知的keys集合。例如，一个用户资料的数据库可以通过姓来分区，A-M属于一个集群，N-Z属于另一个集群。如下：  细心的读者会发现主从架构和分片都在主节点上引入了故障点的问题，事实上，分片技术额外引入了对每个master单点故障的多点故障。此外，含有key的请求信息取决于应用层，并且添加分片需要手动重排数据以适应修改的key范围。 有些系统使用分片管理作为一个在应用层和物理分片之间的抽象层。这样做的好处是应用层不需要知道分区的映射关系。但是，随着集群的增长，还是不能避免需要对数据进行重排。 ### 接管故障的主节点 ---- 提升可用性的一种通用方式是实现主备倒换协议。主备倒换协议有很多种实现，但是一个基本准则是原有主节点宕机时再分配一个新的主节点。并非所有主备倒换算法都相同; 但是，一般情况下主备倒换协议都可以提升主从系统的可用性。 即使是实现了选主协议的主从数据库还是存在许多缺点： ​ 应用必须了解数据库策略 ​ 数据分区规则需提前规划 ​ 主节点很难扩容 ​ 主备倒换增加系统复杂性，尤其对多节点的数据库 ​ 扩容需要重排数据，并有可能导致停机 考虑到我们的目标是一个高度可用的系统，并且假设可扩展性是一个关心的问题，我们还需要考虑其他选择吗？ ## 打破传统 – Cassandra's 选择 实际情况是，并非每个应用程序中的每个事务都需要保证完整的ACID，ACID特性本身可以被视为一个连续统一体，其中给定的事务可能需要不同程度的每个属性。 Cassandra的可用性方法考虑了这一连续性。对比其他的关系型数据库，和同时代的大多数NoSQL相比，其原始架构考虑可用性作为关键的设计目标，旨在实现在服时间100%的难以实现的目标。Cassandra提供了许多旋钮，可以为用户提供高度精细的ACID属性控制，所有这些都有不同的权衡。 ## Cassandra's 对等节点架构 不像单体应用或者主从架构设计，cassandra完全采用对等节点架构。不管数据被写入或者请求到集群的任何一个节点，cassandra集群中所有的节点都可以接受读写请求，内部节点通信采用的是gossip协议，gossip协议可以在不需要主节点的情况下，迅速同步节点之间的元数据信息。 这是一种功能强大的设计，因为它意味着系统本身具有固有的可用性和大规模可扩展性。 请考虑以下图表：  注意同单机和master-slave的结构进行对比，该结构没有特殊节点。事实上，所有的节点本质上一样，因此cassandra没有单点故障，不再不要复杂的sharding或者leader选举。但现在的cassandra如何避免sharding？ ### 一致性哈希 Cassandra使用了一种数据结构可以让任意节点根据指定key轻松定位到数据所在节点，有了这种数据结构，使得Cassandra可以兼顾可用性和可拓展性。这种数据结构就是基于Amazon Dynamo 架构的分布式哈希表(distributed hash table DHT)。 正如我们之前看到的图，Cassandra的拓扑结构是一个哈希环，每个节点负责环上的一部分数据。通过一致性哈希算法将key分配给特定节点，在这期间允许添加或删除节点，而无需基于新范围重新哈希每个key。 拥有给定key的节点由所选分区器（partitioner)确定。Cassandra附带了几个分区器（partitioner）实现，或者开发人员可以通过实现Java接口来定义自己的分区器（partitioner）。 这些话题在下章用大量细节来阐述。 ### 多节点复制 分布式数据库最重要的一个方面是处理集群中数据复制的方式。如果每个分区(partition)仅仅被存储在一个单节点，系统将很有可能会出现单点故障，并且任何一个节点故障都会导致灾难性的数据丢失。因此，这样的系统必须能够跨多个节点复制数据，尽可能的避免数据丢失的情况。 Cassandra拥有先进的副本策略，可提供机架和数据中心感知功能。这意味着它可以配置这样的复制策略，即使发生了如交换机故障，网络分区或数据中心中断等灾难性事件，数据库依然可以对外提供服务。Cassandra同样可以处理在节点故障的情况下，也可以维持原有的副本策略。 多数据中心复制 也许cassandra为实现高可用提供的最独特的特性是多数据中心复制系统。这个系统可以很容易的被配置来通过数据通过物理的或者虚拟的数据中心。这有利于地理位置分散的数据中心放置，而无需复杂的方案来保持数据同步。它还允许您为在线事务和繁重的分析工作负载创建单独的数据中心，同时允许在一个数据中心中写入的数据立即反映在其他数据中心中。 ### 一致性级别 和副本策略紧密关联的是一致性级别，ACID中的C想要保持副本的同步。Cassandra通常被称为最终一致性的系统，这个术语可能会让那些习惯了使用强一致性的关系型数据库的人感到恐慌。然而，正如前面讨论的，一致性应该被认为一个连续统一体，并不是绝对的。 考虑到这一点，Cassandra可以更准确地描述为具有可调整的一致性，其中可以在持久性级别上指定精确的一致性保证程度。这使应用程序架构师能够最终控制调用级别的一致性，可用性和性能之间的权衡，而不是在每个用例上强制实施一刀切的策略。 CAP理论 如果没有考虑CAP理论，任何关于一致性的讨论都是不完整的。CAP首字母缩写是指复制系统中的三个理想属性： ​ Consistency：数据在集群中的所有节点应该相同。 ​ Availability: 系统应该始终可以处理请求。 ​ Partition tolerance(分区容错性): 系统应在部分故障时继续运行. 2000年，加利福尼亚伯克利大学的Eric Brewer计算机教授认为，多副本服务只能选择任何给定操作的三个属性中的两个。 CAP定理被广泛误用，表明整个系统必须只选择两个属性，这导致许多人将数据库定义为AP或CP。 事实上，大多数系统都不适合任何一种类型，而Cassandra也不例外。 Brewer本人在他的2012年文章“十二年后的CAP：规则如何改变”中解决了这种错误的解释： “..所有三个属性都比二进制更连续。 可用性显然是从0到100％连续，但也有很多级别的一致性，甚至分区也有细微差别，包括系统内部是否存在分区存在分歧” 在该文章中，Brewer也指出在ACID范围的一致性定义和CAP的一致性定义不同。在ACID中，一致性是指保证遵循所有数据库规则（唯一约束，外键约束等）。另一方面，如Brewer所说的，CAP的一致性仅指单拷贝一致性，是ACID一致性的严格子集。 在考虑Cassandra一致性级别选项的各种权衡时，重要的是要记住CAP属性存在于连续体而不是二元选择上。 最重要的是，在设计基于Cassandra的系统时，牢记这一连续性非常重要。 有关在各种情况下正确调整Cassandra一致性级别的其他详细信息，请参阅第3章“复制”。 ## 小结 本章节，我们讨论了cassandra的可用性方法，并且为什么做出这个基本设计。这本书的剩余部分基于这个基础来构成。我们将讨论以下主题：如何配置Cassandra以实现高可用性，在Cassandra上设计高可用性应用程序，避免常见的反模式，以及处理各种故障情况。 在本书的最后，您应该牢牢掌握这些概念，并确信您已成功部署了最强大和可扩展的数据库之一。 但是，我们需要一步一步，所以在接下来的几章中，我们将更深入地了解Cassandra如何管理数据。 这个基础对于本书后面讨论的主题是必要的。 我们将在下一章开始讨论Cassandra的数据放置策略。

往期回顾+材料下载：https://bbs.huaweicloud.com/forum/thread-13022-1-1.htmlCloud Native LIves 直播 【Istio服务网格系列】第6课《Istio Mixer架构设计与应用》01月10日 晚 20：00-21:00 直播可选择以下观看方式：1、在线直播及回放地址：http://zhibo.huaweicloud.com/watch/26968162、手机扫码收看：（直播及回放观看二维码）（欢迎回帖提问，会邀请讲师回复问题，也可以现场向讲师发问！参与直播互动还有惊喜哦！）本期课程介绍：【Cloud Native Lives 】直播系列 于每周四晚20：00-21：00 举行直播，每期给您丰富的知识体验！每期直播预告+材料下载，请点击收藏本帖：https://bbs.huaweicloud.com/forum/thread-13022-1-1.html演讲材料下载：【Cloud Native Lives】 第6课：Mixer 功能架构与实践.pdf( 预览 )【品牌课程介绍】Cloud Native：云原生是云计算必然的发展方向。自从Cloud2.0时代来临，许多公司都希望完成传统应用到云端的迁移，但是这个过程中会遇到一些技术难题。云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生的出现，可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策。Cloud Native Lives ：系列直播将带你走进云原生技术的核心，深入浅出的为您讲解云原生技术的方方面面：容器化、微服务、动态管理。结合CNCF（Cloud Native Computing Foundation）社区的成功项目，为您剖析它们的原理及核心技术架构，并在课程中进行实践操作，帮助您快速理解掌握云原生的内涵。讲师团队：主要由华为云容器服务团队的核心架构师组成，包括多名CNCF社区的maintainer、committer，负责、参与了多个CNCF社区项目的设计和开发，将带给您最原汁原味云原生讲解。

点击下载ppt完整版【热门活动】寻找超级算法大师-挑战最优算法，赢取荣耀8X！跳转链接：https://bbs.huaweicloud.com/forum/thread-13282-1-1.html