分布式架构

背景 这两年互联网行业掀着一股新风，总是听着各种高大上的新名词。大数据、人工智能、物联网、机器学习、商业智能、智能预警啊等等。 以前的系统，做数据可视化，信息管理，流程控制。现在业务已经不仅仅满足于这种简单的管理和控制了。数据可视化分析，大数据信息挖掘，统计预测，建模仿真，智能控制成了各种业务的追求。 “所有一切如泪水般消失在时间之中，时间正在死去“ ，以前我们利用互联网解决现实的问题。现在我们已经不满足于现实，数据将连接成时间序列，可以往前可以观其历史，揭示其规律性，往后可以把握其趋势性，预测其走势。 于是，我们开始存储大量时间相关的数据(如日志，用户行为等)，并总结出这些数据的结构特点和常见使用场景，不断改进和优化，创造了一种新型的数据库分类——时间序列数据库(Time Series Database). 时间序列模型 时间序列数据库主要用于指处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。 每个时序点结构如下： timestamp: 数据点的时间，表示数据发生的时间。 metric: 指标名，当前数据的标识，有些系统中也称为name。 value: 值，数据的数值，一般为double类型，如cpu使用率，访问量等数值，有些系统一个数据点只能有一个value，多个value就是多条时间序列。有些系统可以有多个value值

2月19日-2月26日，蚂蚁金服开展了“共战‘疫情’，技术破局”数字课堂线上直播，邀请资深专家从“云原生”、“研发效能”、“数据库”三方面分享蚂蚁金服的实践经验并在线答疑，解析 PaaS 在金融场景的落地建设实践，解析支付宝移动端弹性动态架构，分享 OceanBase 2.2版本的特性和实践。 本文根据 蚂蚁金服 SOFAStack 产品专家俞仁杰 ，在蚂蚁金服数字课堂直播间分享的云原生应用 PaaS 平台的建设实践内容整理，以下为演讲整理全文： 大家好，欢迎来到蚂蚁金服数字课堂直播间。今年 2 月，SOFAStack 金融分布式架构产品已经在阿里云上完成了商业化发布，为了让更多朋友了解到我们的产品的能力、定位以及背后的设计思路，后续我们会有一系列的直播分享。我们今天想分享给大家的话题叫《 云原生应用 PaaS 平台的建设实践 》，主要会围绕 PaaS 产品能力在一些需要稳妥创新的金融场景下的落地思路，并且能够更好地与云原生架构做好链接。 金融场景云原生落地面临挑战 云原生是业务快速变化背景下的必然技术趋势 回顾 IT 的发展史，云计算分类为 IaaS PaaS 和 SaaS 已经有十几年了。而事实上，整个云计算行业的发展，我们能够明显看到企业在落地云计算战略的时候经历的三个阶段，Cloud-Based, Cloud-Ready, Cloud-Native

分布式技术地图 按照业务的架构层次栈，我自底向上按照资源、通信、数据与计算的维度，梳理出了 4 个技术层次：分布式资源池化、分布式通信、分布式数据存储与管理、分布式计算 符合了架构设计的规律，在一定资源上，进行一定通信，通过一定计算，完成一定数据的加工和处理，从而对外提供特定的服务． 因为在分布式架构下需要去解决：协同、调度、追踪高可用，还有部署的问题．那么就可以从横向的技术层次，提炼出分布式协同、分布式调度、分布式追踪与高可用、分布式部署 4 个纵向技术线． 分布式的发展 １单兵模式：单机模式 比如： 所有的模块都在一台机器上，请求处理和数据部署都可能在一台机器上 好处：功能、代码和数据集中，便于维护、管理和执行 缺点：硬件系能提升是有限的，不可能无限的提高cpu等硬件性能．性价比也需要考虑． 除此之外，还会有单点失效的问题，一台机崩溃，所有的服务都不能用 ２游击队模式：数据并行或数据分布式 在单兵模式下，进行数据的拆分，执行的步骤： 一　将应用与数据分离，分别部署到不同的服务器上 二　把数据按照系统进行拆分 拆分以后系统就开始变的稍微复杂一些，需要相应的解决一些问题： １要考虑负载均衡的问题，让每台机器的处理都比较均衡 ２请求量大了，数据库的io就变成了瓶颈，那么就要进行数据库的读写分离，同时要考虑读写数据库的数据同步问题就要 ３某些系统的数据库会成为热点服务器

背景 这两年互联网行业掀着一股新风，总是听着各种高大上的新名词。大数据、人工智能、物联网、机器学习、商业智能、智能预警啊等等。 以前的系统，做数据可视化，信息管理，流程控制。现在业务已经不仅仅满足于这种简单的管理和控制了。数据可视化分析，大数据信息挖掘，统计预测，建模仿真，智能控制成了各种业务的追求。 “所有一切如泪水般消失在时间之中，时间正在死去“，以前我们利用互联网解决现实的问题。现在我们已经不满足于现实，数据将连接成时间序列，可以往前可以观其历史，揭示其规律性，往后可以把握其趋势性，预测其走势。 于是，我们开始存储大量时间相关的数据(如日志，用户行为等)，并总结出这些数据的结构特点和常见使用场景，不断改进和优化，创造了一种新型的数据库分类——时间序列数据库(Time Series Database). 时间序列模型 时间序列数据库主要用于指处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。 每个时序点结构如下： timestamp: 数据点的时间，表示数据发生的时间。 metric: 指标名，当前数据的标识，有些系统中也称为name。 value: 值，数据的数值，一般为double类型，如cpu使用率，访问量等数值，有些系统一个数据点只能有一个value，多个value就是多条时间序列。有些系统可以有多个value值

为什么要用分布式锁 使用场景 xx游戏平台举办了一个回馈用户活动，只要等级达到x等级，即可领取xx装备。可能有些人，有过这样的想，是不是，只要我速度够快，就能领到多份奖品啊，想想都美滋滋。结果，系统显示， 当前操作过于频繁，请稍后再试 。what??? 这个的话，就涉及到了锁。同个账号，当我们的第一次请求到服务器的时候，已经被加上了锁，当还没释放锁的时候，再次请求，则不能拿到锁，只能继续等待。(当然这种场景不一定要用分布式锁进行实现，比如数据库的索引唯一性也可实行，只是举个例子) 说到锁的话，则要从公司系统的架构说起了。一开始，很多公司的系统不是很庞大，为了节省资源，单机即可满足需求。对于这种单机模式的系统，我们可以用java原生的synchronized和lock这两种锁，只要锁住相应的类、对象或者方法等即可简单的时间锁机制。 但随着公司的不断发展，用户量的增加，需要对业务进行拆分。这个时候，微服务就出现了，服务拆分了，同时为了保证高可用，每个服务会根据负载等因素，选择部署不同数量的机器，进行集群管理。 在分布式系统的话，则出现了同个服务，部署在不同的机器上。因为我们上面采用的是基于JVM的锁机制，没法保证同个用户请求的锁都是同个JVM（其实可以通过设置负载均衡策略，根据用户id进行hash之类，让用户落到同一台机器上，但这种很少用，毕竟这个是属于业务的问题）

GitHub上整理的一些工具 GitHub 2015-11-19 10:10:47 发布 您的评价: 0.0 收藏 5收藏 技术站点 Hacker News：非常棒的针对编程的链接聚合网站 Programming reddit：同上 MSDN：微软相关的官方技术集中地，主要是文档类 infoq：企业级应用，关注软件开发领域 OSChina：开源技术社区，开源方面做的不错哦 cnblogs，51cto，csdn：常见的技术社区，各有专长 stackoverflow：IT技术问答网站 GitHub：全球最大的源代码管理平台，很多知名开源项目都在上面，如Linux内核， OpenStack等免费的it电子书： http://it-ebooks.info/ DevStore:开发者服务商店 不错的书籍 人件 人月神话 代码大全2 计算机程序设计艺术 程序员的自我修养 程序员修炼之道 高效能程序员的修炼（成为一名杰出的程序员其实跟写代码没有太大关系） 深入理解计算机系统 软件随想录 算法导论（麻省理工学院出版社） 离线数学及其应用 设计模式 编程之美 黑客与画家 编程珠玑 C++ Prime Effective C++ TCP/IP详解 Unix 编程艺术 《精神分析引论》弗洛伊德 搞定：无压力工作的艺术 平台工具（都是开源的好东东哦） Redmine/Trac：项目管理平台 Jenkins

背景 这两年互联网行业掀着一股新风，总是听着各种高大上的新名词。大数据、人工智能、物联网、机器学习、商业智能、智能预警啊等等。 以前的系统，做数据可视化，信息管理，流程控制。现在业务已经不仅仅满足于这种简单的管理和控制了。数据可视化分析，大数据信息挖掘，统计预测，建模仿真，智能控制成了各种业务的追求。 “所有一切如泪水般消失在时间之中，时间正在死去“ ，以前我们利用互联网解决现实的问题。现在我们已经不满足于现实，数据将连接成时间序列，可以往前可以观其历史，揭示其规律性，往后可以把握其趋势性，预测其走势。 于是，我们开始存储大量时间相关的数据(如日志，用户行为等)，并总结出这些数据的结构特点和常见使用场景，不断改进和优化，创造了一种新型的数据库分类——时间序列数据库(Time Series Database). 时间序列模型 时间序列数据库主要用于指处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。 每个时序点结构如下： timestamp: 数据点的时间，表示数据发生的时间。 metric: 指标名，当前数据的标识，有些系统中也称为name。 value: 值，数据的数值，一般为double类型，如cpu使用率，访问量等数值，有些系统一个数据点只能有一个value，多个value就是多条时间序列。有些系统可以有多个value值

HDFS全称为Hadoop Distributed File System，是整个Hadoop平台上的两大核心组件之一 HDFS用于解决海量数据的分布式存储问题 计算机集群结构 分布式文件系统把文件分布存储到多个计算机节点上，成千上万的计算机节点构成计算机集群 与之前使用多个处理器和专用高级硬件的并行化处理装置不同的是，目前的分布式文件系统所采用的计算机集群，都是由普通硬件构成的，这就大大降低了硬件上的开销 机架内部的机器通过光纤高速交换机进行连接，机架和机架之间通过带宽更高的几个光纤交换机来完成彼此之间的交互和连接 分布式文件系统的结构 分布式文件系统在物理结构上是由计算机集群中的多个节点构成的，这些节点分为两类，一类叫“主节点”(Master Node)或者也被称为“名称结点”(NameNode)，另一类叫“从节点”（Slave Node）或者也被称为“数据节点”(DataNode)一个作为主节点，其余作为从节点，主节点承担起数据目录（元数据）服务，从节点要具体完成数据的存储任务 HDFS简介 HDFS要实现以下目标： 兼容廉价的硬件设备 流数据读写 大数据集 简单的文件模型 强大的跨平台兼容性 传统的文件系统在进行数据读写的时候是以块数据为单位，每一次可以读取指定的某一部分数据，而HDFS设计的目标就是对大量数据的读写，不会访问某个文件的子集或去访问一块一块的数据

一、分布式事务前奏 事务：事务是由一组操作构成的可靠的独立的工作单元，事务具备ACID的特性，即原子性、一致性、隔离性和持久性。 本地事务：当事务由资源管理器本地管理时被称作本地事务。本地事务的优点就是支持严格的ACID特性，高效，可靠，状态可以只在资源管理器中维护，而且应用编程模型简单。但是本地事务不具备分布式事务的处理能力，隔离的最小单位受限于资源管理器。 全局事务：当事务由全局事务管理器进行全局管理时成为全局事务，事务管理器负责管理全局的事务状态和参与的资源，协同资源的一致提交回滚。 TX协议：应用或者应用服务器与事务管理器的接口。 XA协议：全局事务管理器与资源管理器的接口。XA是由X/Open组织提出的分布式事务规范。该规范主要定义了全局事务管理器和局部资源管理器之间的接口。主流的数据库产品都实现了XA接口。XA接口是一个双向的系统接口，在事务管理器以及多个资源管理器之间作为通信桥梁。之所以需要XA是因为在分布式系统中从理论上讲两台机器是无法达到一致性状态的，因此引入一个单点进行协调。由全局事务管理器管理和协调的事务可以跨越多个资源和进程。全局事务管理器一般使用XA二阶段协议与数据库进行交互。 AP：应用程序，可以理解为使用DTP（Data Tools Platform）的程序。 RM：资源管理器，这里可以是一个DBMS或者消息服务器管理系统

随着大型网站的各种高并发访问、海量数据处理等场景越来越多，如何实现网站的高可用、易伸缩、可扩展、安全等目标就显得越来越重要。为了解决这样一系列问题，大型网站的架构也在不断发展。提高大型网站的高可用架构，不得不提的就是分布式。本文主要简单介绍了分布式系统的概念、分布式系统的特点、常用的分布式方案以及分布式和集群的区别等。 一、集中式系统 在学习分布式之前，先了解一下与之相对应的集中式系统是什么样的。 集中式系统用一句话概括就是：一个主机带多个终端。终端没有数据处理能力，仅负责数据的录入和输出。而运算、存储等全部在主机上进行。现在的银行系统，大部分都是这种集中式的系统，此外，在大型企业、科研单位、军队、政府等也有分布。集中式系统，主要流行于上个世纪。 集中式系统的最大的特点就是部署结构非常简单，底层一般采用从IBM、HP等厂商购买到的昂贵的大型主机。因此无需考虑如何对服务进行多节点的部署，也就不用考虑各节点之间的分布式协作问题。但是，由于采用单机部署。很可能带来系统大而复杂、难于维护、发生单点故障（单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪）、扩展性差等问题。 二、分布式系统(distributed system) 在《分布式系统概念与设计》一书中，对分布式系统做了如下定义： 分布式系统是一个硬件或软件组件分布在不同的网络计算机上