分布式开发

1.安装docker toolbox 1）在官网上下载OS上需要的docker toolbox。 2）下载完成后，像安装OS上的软件一样来安装docker toolbox。安装完成后，你会发现此时安装了一个virtualbox。同时也安装了docker的相关命令，比如docker-machine等。 2.安装docker虚拟机 利用上述步骤安装的docker-machine来安装一个docker虚拟机，名字为default，命令是docker-machine run default. 此时就会创建一个虚拟机叫做default。 3.连接虚拟机 这里直接给出命令了:docker-machine ssh default.如果你再宿主机上安装了多个虚拟机，你可以使用docker-machine ls来查看。同时，你也可以使用docker-machine env default来查看虚拟机的信息。 4.拉取镜像 通过第三步以后，你已经连接上虚拟机了。因此，你可以直接在里面来拉取docker的镜像了。我这里拉取了ubuntu最新的镜像。命令是docker pull ubuntu ，针对国内下载镜像很慢的情况，国内的DaoCloud做了一个镜像，在使用他的镜像之前，你需要在虚拟机上使用命令来安装他的一个加速器，安装加速器后，速度蹭蹭往上加快。命令是：curl -sSL https://get

你如何考虑服务化 # 集中式与分布式 要谈微服务，那么必须建立在分布式的基础上，对于一个集中式系统也无需谈微服务。 # 集中式 集中式系统用一句话概括就是：一个主机带多个终端。终端没有数据处理能力，仅负责数据的录入和输出。而运算、存储等全部在主机上进行。 集中式系统的最大的特点就是部署结构非常简单，底层一般采用从IBM、HP等厂商购买到的昂贵的大型主机。因此无需考虑如何对服务进行多节点的部署，也就不用考虑各节点之间的分布式协作问题。但是，由于采用单机部署。很可能带来系统大而复杂、难于维护、发生单点故障（单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪）、扩展性差等问题。 # 分布式 分布式就是一群独立计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务一样。分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源等也就越多，能够处理的并发访问量也就越大。 拿电商网站来说，我们一般把一个电商网站横向拆分成商品模块、订单模块、购物车模块、消息模块、支付模块等。然后我们把不同的模块部署到不同的机器上，各个模块之间通过远程服务调用( RPC )等方式进行通信。以一个分布式的系统对外提供服务。 # 服务化 提到分布式，一个不得不提的词就是服务化

一.软件架构的演进 1.单体结构 前端+中间件业务逻辑层+数据库层 2.分布式应用 中级架构，分布式应用 中间层分布式+数据库分布式 解决了高并发问题，降低了耦合度，责任清晰，扩展方便，部署方便，提高代码的复用性。 系统交互要使用远程通信，接口开发增大工作量 3.微服务架构 中间层分解，将系统拆分为很多的小应用（微服务） 4.Serverless架构 二.23种设计模式（日记中有） 三.今日份Java问题 1.JDK、JRE、JVM三者之间的关系，以及JDK、JRE包含的主要结构有哪些 2.为什么要配置path环境变量，如何配置 3.常见的几个命令行操作有哪些 来源： https://www.cnblogs.com/codekaterina/p/11891995.html

写在前面 https://www.cnblogs.com/gengzhe/p/ray_actor.html Orleans是基于Actor模型思想的.NET领域的框架，它提供了一种直接而简单的方法来构建分布式大规模计算应用程序，而无需学习和应用复杂的并发或其他扩展模式。我在2015年下半年开始应用Orleans，当时公司的交易系统采用的架构就是基于Orleans框架的，其展现出来的高性能、高并发以及惊人的稳定性深深地吸引了我，也让我认识到了传统三层无状态架构的缺陷。本文主要关注Orleans的思想基础，Actor模型及其应用。 Orleans思想基础：Actor模型 传统三层无状态架构的缺陷 在讨论Actor模型之前，我们可以先讨论一下传统三层架构在当前高并发环境中所面临的尴尬境遇。 三层架构包括表示层、业务逻辑层或者叫做中间层、数据访问层（也就是存储层），其架构图如下所示： 正如我们在实践中所知道的那样，中间层和数据访问层在伸缩性方面有着很大的限制，同时存储层常常会成为系统的瓶颈，这就意味着整套系统也会因为存储层的限制而变得低效。通常的做法是在中间层与存储层中间加一层缓存逻辑出来，以提升系统性能，但是很快就会遇到存储层与缓存层的数据一致性问题，这无疑为开发人员和运维人员增加了额外的工作量。 试想一下，如果我们中间层本身就携带着状态或者简单来说中间层与缓存层是合二为一的

zookeeper+KAFKA 集群搭建 ZooKeeper是一个分布式的1600174884，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、集群管理等。因为Kafka集群是把状态信息保存在Zookeeper中的，并且Kafka的动态扩容是通过Zookeeper来实现的，所以需要优先搭建Zookeerper集群，建立分布式状态管理。开始准备环境，搭建集群： zookeeper是基于Java环境开发的所以需要先安装Java 然后这里使用的zookeeper安装包版本为zookeeper-3.4.14，Kafka的安装包版本为kafka_2.11-2.2.0。 AMQP协议：Advanced Message Queuing Protocol （高级消息队列协议）是一个标准开放的应用层的消息中间件协议。AMQP定义了通过网络发送的字节流的数据格式。因此兼容性非常好，任何实现AMQP协议的程序都可以和与AMQP协议兼容的其他程序交互，可以很容易做到跨语言，跨平台。 server1：192.168.42.128 server2：192.168.42.129 server3：192.168.42.130

随着各个业务系统的不断增加，以及各业务系统数据量不断激增，业务用户的分析诉求越来越多且变化很快，IT数据支撑方的工作变得越来越复杂。 1、数据来自多个不同的系统，存在需要跨数据源分析，需要对接各种不同数据源等问题。 2、需要分析的数据体量越来越大，并且要快速获得分析结果的问题。 3、部分数据还需要二次加工处理的问题。 供数支撑方在业务系统的前端看起来基本没有任何操作，但背后的逻辑十分复杂，实现难度也很大。就像看得到的是冰山一角，看不到的是海水下绝大部分的支撑。 为了解决日益激增的大数据量分析诉求，大部分公司会通过搭建Hadoop、Spark等大数据架构，配以BI工具做数据层面的分析，来搭建这样一整套大数据分析平台。 大数据分析很关键的一个点在于性能：取数快不快，分析响应快不快，能否实时？ 这个问题除了平台的底层架构，BI（ 商业智能 ）的运行性能也有很大相关。 大家可能普遍认为的BI，就是一个数据展现工具，在前端看起来没有太多有技术含量的操作，但背后的逻辑十分复杂，实现难度也很大。就像看得到的是冰山一角，看不到的是海水下绝大部分的支撑。 好的BI工具都有与之依赖的数据引擎，数据引擎的作用一方面是数据响应的性能（数据量、速率），还有很重要的一点是能否适应企业不同业务情况的模式/方案。比如小数据快速读取，大数据分布式并行运算，节点数据实时展现等等..... FineBI V5

摘要： 阿里妹导读：阿里巴巴的电商业务十分复杂，一方面是市场多样化，业务多样化，另外是消费者，商家的影响面非常广，任何一个小故障都可能引发一些社会问题，所以阿里对产品的质量，对服务的连续性有严格的要求。阿里技术人员在日常的研发运维过程中，积累了丰富的实战经验。 阿里妹导读：阿里巴巴的电商业务十分复杂，一方面是市场多样化，业务多样化，另外是消费者，商家的影响面非常广，任何一个小故障都可能引发一些社会问题，所以阿里对产品的质量，对服务的连续性有严格的要求。阿里技术人员在日常的研发运维过程中，积累了丰富的实战经验。今天，阿里妹将为大家分享一个关于故障，排查，分析和改进的真实案例。他山之石可以攻玉，希望对广大开发和运维工程师带来帮助。 背景说明 某日，做产品X的开发接到客户公司电话，说是对账出了1分钱的差错，无法处理。本着“客户第一”的宗旨，开发立马上线查看情况。查完发现，按照产品X当日的年化收益率，正常情况下用户在转入57元后一共收益3分钱，合计是57.03元。但是该客户当日却有一笔消费57.04元，导致客户公司系统对多出的1分钱处理不了。再进一步分析，发现用户收益结转时多了1分钱的收益，并且已消费…… 也就是说，本来用户只有3分钱收益，结果多发了1分钱给他，也就给公司造成1分钱的损失！用户在产品X里当天收益本应该是0.03元，怎么会变成0.04元呢？多出的1分钱收益从哪里来的呢？

1、Zookeeper 的由来 在Hadoop生态系统中，许多项目的Logo都采用了动物，比如 Hadoop 和 Hive 采用了大象的形象，HBase 采用了海豚的形象，而从字面上来看 ZooKeeper 表示动物园管理员，所以大家可以理解为 ZooKeeper就是对这些动物（项目组件）进行一些管理工作的。 对于单机环境多线程的竞态资源协调方法，我们一般通过线程锁来协调对共享数据的访问以保证状态的一致性。 但是分布式环境如何进行协调呢？于是，Google创造了Chubby，而ZooKeeper则是对于Chubby的一个开源实现。 ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务，它提供了一项基本服务：分布式锁服务。由于ZooKeeper的开源特性，后来我们的开发者在分布式锁的基础上，摸索了出了其他的使用方法：配置维护、组服务、分布式消息队列、分布式通知/协调等。它被设计为易于编程，使用文件系统目录树作为数据模型。 2、ZooKeeper集群模式典型架构 2.1 角色 Zookeeper服务自身组成一个集群(2n+1个服务允许n>=1个失效)。Zookeeper集群是一个基于主从复制的高可用集群，每个服务器承担如下三种角色中的一种 Leader 一个Zookeeper集群同一时间只会有一个实际工作的Leader

fastDSF介绍 　　FastDFS是用c语言编写的一款开源的分布式文件系统，它是由淘宝资深架构师余庆编写并开源。FastDFS专为互联网量身定制，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标，使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。 为什么要使用fastDFS呢？ 　　NFS、GFS都是通用的分布式文件系统，通用的分布式文件系统的优点的是开发体验好，但是系统复杂性高、性能一般，而专用的分布式文件系统虽然开发体验性差，但是系统复杂性低并且性能高。fastDFS非常适合存储图片等那些小文件，fastDFS不对文件进行分块，所以它就没有分块合并的开销，fastDFS网络通信采用socket，通信速度很快。 来源： https://www.cnblogs.com/yanxiaoge/p/11853758.html

由于数据量的巨大，大部分Web应用都需要部署很多个数据库实例。这样，有些用户操作就可能需要去修改多个数据库实例中的数据。传统的解决方法是使用分布式事务保证数据的全局一致性，经典的方法是使用两阶段提交协议。 长期以来，分布式事务提供的优雅的全局ACID保证麻醉了应用开发者的心灵，很多人都不敢越雷池一步，想像没有分布式事务的世界会是怎样。如今就如MySQL和PostgreSQL这类面向低端用户的开源数据库都支持分布式事务了，开发者更是沉醉其中，不去考虑分布式事务是否给系统带来了伤害。 事实上，有所得必有所失，分布式事务提供的ACID保证是以损害系统的可用性、性能与可伸缩性为代价的。只有在参与分布式事务的各个数据库实例都能够正常工作的前提下，分布式事务才能够顺利完成，只要有一个工作不正常，整个事务就不能完成。这样，系统的可用性就相当于参加分布式事务的各实例的可用性之积，实例越多，可用性下降越明显。从性能和可伸缩性角度看，首先是事务的总持续时间通常是各实例操作时间之和，因为一个事务中的各个操作通常是顺序执行的，这样事务的响应时间就会增加很多；其次是一般Web应用的事务都不大，单机操作时间也就几毫秒甚至不到1毫秒，一但涉及到分布式事务，提交时节点间的网络通信往返过程也为毫秒级别，对事务响应时间的影响也不可忽视。由于事务持续时间延长，事务对相关资源的锁定时间也相应增加