分布式架构

随着CoreOS和Kubernetes等项目在开源社区日益火热，它们项目中都用到的etcd组件作为一个 高可用、强一致性的服务发现存储仓库 ，渐渐为开发人员所关注。在云计算时代，如何让服务快速透明地接入到计算集群中，如何让共享配置信息快速被集群中的所有机器发现，更为重要的是，如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群，已经成为了迫切需要解决的问题。etcd为解决这类问题带来了福音，本文将从etcd的应用场景开始，深入解读etcd的实现方式，以供开发者们更为充分地享用etcd所带来的便利。 etcd 是一个高可用的 Key/Value 存储系统，主要用于分享配置和服务发现。etcd 的灵感来自于 ZooKeeper 和 Doozer，側重于： 简单 ：支持 curl 方式的用户 API (HTTP+JSON) 安全 ：可选 SSL client证书认证 高速 ：单实例可达每秒 1000 次写操作 可靠 ：使用 Raft 实现分布式 Etcd is written in Go and uses the raft consensus algorithm to manage a highly-available replicated log. 经典应用场景 要问etcd是什么？很多人第一反应可能是一个键值存储仓库，却没有重视官方定义的后半句，用于 配置共享和服务发现 。

CAP原则 分布式–CAP原则 CAP理论是指分布式系统架构中通常只能够满足CAP三个指标中的两个，而不能同时满足CAP三个指标。 C（Consistency）：一致性 一致性指的是All nodes see the same data at the same time，也就是说所有节点在同一时间看到的数据必须是一模一样的 ，比如足球比赛中，当比分发生了改变，客户端A看到的比分是1:0，而客户端B看到的比分还是0:0；又比如在银行系统中，通过微信进行银行卡转账，卡上余额从100变成了0，但是在支付宝中查看银行卡余额还是100，这显然就破坏了数据的一致性。 A（Avalilability）：可用性 可用性指的是Reads and writes always succeed，也就是说无论是读操作还是写操作，始终是成功的，也就是服务一直可用，不存在服务失败或者用户操作失败的情况 。比如说用户发起提现操作，过了会显示提现失败；在进行转账的时候提示了需要等2天后才能到账，显然就破坏了可用性，因为用户的一系列操作换来的是提现失败，转账延迟才能到账，而不是立马响应到账。 P（ Partition Toleranc）：分区容错性 分区容错性指all nodes look like one node，也就是说多个节点的运行看起来就像是一个节点在运行一样，一个节点宕机不可用，其他节点还可以正常运行

这可能是把ZooKeeper概念讲的最清楚的一篇文章 相信大家对 ZooKeeper 应该不算陌生，但是你真的了解 ZooKeeper 是什么吗？如果别人/面试官让你讲讲 ZooKeeper 是什么，你能回答到哪个地步呢？ 作者：SnailClimb来源： 51CTO技术栈 |2018-09-12 09:34 收藏 分享 我本人曾经使用过 ZooKeeper 作为 Dubbo 的注册中心，另外在搭建 Solr 集群的时候，我使用到了 ZooKeeper 作为 Solr 集群的管理工具。 前几天，总结项目经验的时候，我突然问自己 ZooKeeper 到底是个什么东西？ 想了半天，脑海中只是简单的能浮现出几句话： Zookeeper 可以被用作注册中心。 Zookeeper 是 Hadoop 生态系统的一员。 构建 Zookeeper 集群的时候，使用的服务器最好是奇数台。 可见，我对于 Zookeeper 的理解仅仅是停留在了表面。所以，通过本文，希望带大家稍微详细的了解一下 ZooKeeper 。 如果没有学过 ZooKeeper，那么本文将会是你进入 ZooKeeper 大门的垫脚砖；如果你已经接触过 ZooKeeper ，那么本文将带你回顾一下 ZooKeeper 的一些基础概念。 最后，本文只涉及 ZooKeeper 的一些概念，并不涉及 ZooKeeper 的使用以及

注：文章转自https://www.runoob.com/w3cnote/github-tools.html 技术站点 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/Jira

引言 在跟同行交流的时候，常常有人这样问：中台不就是微服务吗？都是以服务化的方式对外提供能力，老瓶装新酒嘛，炒作概念而已。 这种说法实际上混淆了中台与微服务的定义，要说清楚这个问题，就要先了解，什么是中台？什么是微服务？中台和微服务之间有什么样的关系？ 01 中台是什么？ 1.1 中台的定义 来自阿里官方的定义，“ 企业中台就是，将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新，实现以数字化资产的形态构建企业核心差异化竞争力。 ” 阿里的中台大约有十几个共享业务单元，包括用户中心、商品中心、交易中心等。淘宝、天猫、聚划算等 25 个大型业务应用都是由中台的共享业务单元支持的，共享业务单元则由阿里云平台支持。 共享业务单元的划分原则其实不是可以简单掌握的，要综合考量设计、运营和工程因素，尽可能遵循“高内聚、低耦合”、“数据完整”、“业务可运营”和“渐进”的原则。 阿里在划分中台时非常重视其业务价值和基于业务的设计，而且有业务架构岗位，每个共享单元都有业务架构师。但总体来讲，其业务架构仍然是领域性的。 1.2 代表企业 企业中台最早是由阿里在2015年提出的，即逍遥子张勇倡导的“大中台，小前台”战略、“数据+业务双中台”等等。 随后BAT、TMD纷纷效仿，提出了各家的中台战略

转自： https://blog.csdn.net/zhonglunsheng/article/details/83153451 简单的说，微服务是架构设计方式，分布式是系统部署方式，两者概念不同 微服务是啥？ 这里不引用书本上的复杂概论了，简单来说微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事。这个服务可以单独部署运行，服务之间可以通过RPC来相互交互，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。 微服务架构又是啥？ 在做架构设计的时候，先做逻辑架构，再做物理架构，当你拿到需求后，估算过最大用户量和并发量后，计算单个应用服务器能否满足需求，如果用户量只有几百人的小应用，单体应用就能搞定，即所有应用部署在一个应用服务器里，如果是很大用户量，且某些功能会被频繁访问，或者某些功能计算量很大，建议将应用拆解为多个子系统，各自负责各自功能，这就是微服务架构。 那么分布式又是啥？ 分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的

一、分布式 1.1、分布式-事务 （1）产生背景/基本思想Base和CAP理论： https://blog.csdn.net/RuiKe1400360107/article/details/102711821 （2）分布式事务常见解决方案： https://blog.csdn.net/RuiKe1400360107/article/details/102730601 （3）RabbitMQ解决分布式事务： https://blog.csdn.net/RuiKe1400360107/article/details/102882978 1.2、分布式-分布式协调框架Zookeeper （1）基础概念及常用命令： https://blog.csdn.net/RuiKe1400360107/article/details/103709430 （2）集群搭建与代码整合： https://blog.csdn.net/RuiKe1400360107/article/details/103774721 （3）Zookeeper实现分布式锁： https://blog.csdn.net/RuiKe1400360107/article/details/103796419 （4）解决分布式Session一致性问题、实现哨兵机制（Master选举）： https://blog.csdn.net

搜索引擎选择： Elasticsearch与Solr 搜索引擎选型调研文档 Elasticsearch简介 * Elasticsearch是一个 实时 的 分布式 搜索和分析引擎。它可以帮助你用前所未有的速度去处理大规模数据。 它可以用于 全文搜索 ， 结构化搜索 以及 分析 ，当然你也可以将这三者进行组合。 Elasticsearch是一个 建立在全文搜索引擎 Apache Lucene™ 基础上 的搜索引擎，可以说Lucene是当今最先进，最高效的全功能开源搜索引擎框架。 但是Lucene只是一个框架，要充分利用它的功能，需要使用JAVA，并且在程序中集成Lucene。需要很多的学习了解，才能明白它是如何运行的，Lucene确实非常复杂。 Elasticsearch使用Lucene作为内部引擎，但是在使用它做全文搜索时，只需要使用统一开发好的API即可，而不需要了解其背后复杂的Lucene的运行原理。 当然Elasticsearch并不仅仅是Lucene这么简单，它不但包括了全文搜索功能，还可以进行以下工作: 分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。 实时分析的分布式搜索引擎。 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。 这么多的功能被集成到一台服务器上，你可以轻松地通过客户端或者任何你喜欢的程序语言与ES的RESTful API进行交流

架构设计 软件架构是指在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件，组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。 一、架构设计过程 业界软件架构设计的方法论很多，各有各自的应用场景和特点，下文结合ADMEMS（Architecture Design Method has been Extended to Method System）架构设计方法论说明软件架构的过程： 预架构阶段 目标：全面理解需求；需求结构化，摒弃“需求列表”，建立二维需求观（ADMEMS矩阵）。 方法：使用ADMEMS矩阵方法，捋清需求间关系和发现衍生需求。 具体步骤： 1、与人：与项目经理、需求分析师等内部需求人员了解需求；与客户了解需求（不建议架构师做需求分析师角色）。 2、与物：了解《需求规格说明书》等需求文档。" 3、对需求有什么问题，反馈给售前或销售，可能会参与拜访客户或电话会议。 4、销售或售前有时会要求提供一个大致的工作量，以便他们初步评估项目可行性。 概念架构 目标：高层组件及其关系 方法： 1、初步设计，基于关键功能，借助鲁棒图进行以发现职责为目的的初步设计（不是必须）。 2、高层分割，将复杂系统切分为多个二级系统或多个子系统。 3、考虑非功能需求，采用ADMEMS推荐的目标

一、http_load 程序非常小，解压后也不到100K http_load以并行复用的方式运行，用以测试web服务器的吞吐量与负载。 但是它不同于大多数压力测试工具，它可以以一个单一的进程运行，一般不会把客户机搞死。 还可以测试HTTPS类的网站请求。 下载地址：http_load-12mar2006.tar.gz 安装很简单 #tar zxvf http_load-12mar2006.tar.gz #cd http_load-12mar2006 #make && make install 基本用法： http_load -p 并发访问进程数 -s 访问时间 需要访问的URL文件 参数其实可以自由组合，参数之间的选择并没有什么限制。 比如你写成http_load -parallel 5 -seconds 300 urllist.txt也是可以的。 我们把参数给大家简单说明一下。 -parallel 简写-p ：含义是并发的用户进程数。 -fetches 简写-f ：含义是总计的访问次数 -rate 简写-p ：含义是每秒的访问频率 -seconds 简写-s ：含义是总计的访问时间 准备URL文件：urllist.txt，文件格式是每行一个URL，URL最好超过50－100个测试效果比较好。 文件格式如下： 1、http://www.qixing318.com/ 2、http:/