consul

　分布式系统中主要的问题就是如何保持节点状态的一致性，不论发生任何failure，只要集群中大部分的节点可以正常工作，则这些节点具有相同的状态，保持一致，在client看来相当于一台机器。 　　一致性问题本质就是replicated state machines，即所有结点都从同一个state出发，都经过同样的一些操作序列（log），最后到达同样的state。其中保证各个节点执行相同的操作序列就是raft算法所要实现的。在raft算法中有一个Leader的角色，client与之进行交互，并且Leader协调Follower，保障所有的Follower具有相同的操作序列，最后提交这些操作，使状态机达成一个新的一致的stat。 　　整个raft算法分为Leader选举，日志分发，日志压缩（快照），集群成员变更。其中的Leader选举是算法的核心部分。算法保证任何时候最多只有一个Leader，但是可能没有 Leader（比如正在选举过程中或者集群成员多数不可用时）。在Leader确立之后，就可以进行日志分发，算法保证日志会被安全的分发到集群中并且应用到状态机的日志和自己相同。快照是为了减少日志量，去除中间过程。集群成员变更是为了在不停服务的情况下安全使用新的集群配置。 　　 Raft在非拜占庭错误情况下，包括网络延迟、分区、丢包、冗余和乱序等错误都可以保证正确，不会返回错误结果

前言 Spring Cloud是一个基于Spring Boot实现的云应用开发工具，它为基于JVM的云应用开发中的配置管理、服务注册，服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。 系统架构演变概述 在公司业务初创时期，面对的主要问题是如何将一个想法变成实际的软件实现，在这个时候整个软件系统的架构并没有搞得那么复杂，为了快速迭代，整个软件系统就是由 “App+后台服务” 组成，而后台服务也只是从工程角度将应用进行Jar包的拆分。此时软件系统架构如下： 而此时整个软件系统的功能也比较简单，只有基本的用户、订单、支付等功能，并且由于业务流程没有那么复杂，这些功能基本耦合在一起。而随着App的受欢迎程度（作者所在的公司正好处于互联网热点），所以App下载量在2017年迅猛增长，在线注册人数此时也是蹭蹭往上涨。 随着流量的迅猛增长，此时整个后台服务的压力变得非常大，为了抗住压力只能不断的加机器，平行扩展后台服务节点。此时的部署架构如下： 通过这种方式，整个软件系统抗住了一波压力，然而系统往往还是会偶尔出点事故，特别是因为api中的某个接口性能问题导致整个服务不可用，因为这些接口都在一个JVM进程中，虽然此时部署了多个节点，但因为底层数据库、缓存系统都是一套，所以还是会出现一挂全挂的情况。 另一方面，随着业务的快速发展

转载自公众号： SpringForAll社区 确保你在分布式系统中，努力实现这些微服务的最佳实践，例如监控和REST成熟度。 使用微服务架构可以解决所有的软件架构的问题，对吗？当然，这是不对的。但是，使用微服务架构是有价值的。 Hüseyin Babal 最近发表了一个观点，即微服务架构是无法解决所有的问题的。但是，使用微服务架构是构建现代软件架构的坚实基础。在过去的许多年里，我们都知道维护单体应用而带来的挑战，所以 我们寻找一个新的选择来实现可持续，可扩展，易于集成的软件架构。以最佳实践为基础来实现微服务架构可以大幅度的改善你的软件架构。 Hüseyin 是aurea的首席软件架构师和Kloia的咨询师。他最近的演讲， 微服务架构终极指南 涵盖了他每天工作的大部分的经验和展现了实现微服务架构的最佳实践。 在他的演讲中，它使用Spring Boot来进行应用开发，Consul作为服务发现，Elasticsearrch 和Kibana作为监控，Docker和Jenkins作为持续交付。演讲中包含了十条最佳实践的代码示例演示。 最佳实践1 -- 尝试达到真正的REST 在意识到REST API的好处之后，我们可以查看上图的Leonard Richardson's 的成熟度模型，对于REST的使用有四个级别的定义。 级别0：使用一个端点来访问软件资源 级别1

新型完整的监控告警工具 主要特点： 多维数据模型，时间序列数据由度量名称和键/值对标识 一种灵活的查询语言来利用这种维度 不依赖分布式存储;单个服务器节点是自治的 时间序列收集通过HTTP上的拉模型进行 通过中间网关支持时间序列的推送 通过服务发现或静态配置发现目标 多种模式的绘图和仪表板的支持 机器IP：118.190.107.96 (阿里云) 1、安装 # 下载地址 https://prometheus.io/download/ #prometheus # centos下载linux压缩包即可。 # 上传到服务器 解压 tar xf prometheus-2.17.1.linux-amd64.tar.gz # mv文件夹名称 cd prometheus-2.17.1.linux-amd64 mv prometheus-2.17.1.linux-amd64 prometheus # 更改配置ip vim prometheus.yml # 将 localhost 改成自己的ip地址 如下图 static_configs: - targets: [ '118.190.217.164:9090' ] 2、启动 ./prometheus 3、web ui 登录访问: 118.190.217.164:9090 Prometheus自带有简单的UI prometheus.yml的配置

正文共729字 预计阅读时间：2分钟😂 相信大家看过 《听说，你的Loki还是单体?(上篇)》 之后对Loki的分布式架构有了一定的认识 ，那么本篇主要就是对上篇内容的实践。小白主要提供 docker-compose 和 helm 两种方式将部署Loki集群的Demo版本。 在正式部署之前，我们还是先来看下Loki整体架构如下图： 我们本次部署清单里面主要涉及到的组件如下： 组件 副本数 说明 Cassandra 1 Loki Index存储 Minio 1 Loki S3存储 Consul 1 Loki 组件状态和哈希环存储 Redis 1 Loki 缓存 Gateway 2 Loki 网关 Distributor 3 Loki 组件 Ingester 3 Loki 组件 Querier 3 Loki 组件 Query-Frontend 2 Loki 组件 Table-Manager 1 Loki 组件 下载部署代码 $ git clone https://github.com/CloudXiaobai/loki-cluster-deploy.git 声明：以下部署均适用于demo环境，大家切勿直接用于生产环境 对于生产环境，请务必先解决Cassandra和Consul服务的高可用 通过docker-compose部署 启动服务 $ cd loki-cluster-deploy

面对可能出现的网络延迟，不可预估的请求流量等情况，设计一个分布式系统，我们通常围绕系统高可用，数据一致性的目标去规划和实现，想要完全实现这个目标，却并非易事。由此，分布式系统领域诞生了一个基本定理，即 CAP 定理，用于指导分布式系统的设计，从系统高可用，数据一致性，网络容错三个角度将分布式系统的特性抽成一个分区容错一致性模型。这样一来，让系统设计者只需根据业务场景特点，进行权衡设计适合业务场景的分区容错一致性模型即可，很大程度简化了分布式系统设计的难度。 也因此，CAP 定理是架构师所必须要掌握的内容，它影响着架构师对分布式系统的技术选型，技术决策。既然如此重要，接下来，我们就一起学习下 CAP 定理吧。 什么是 CAP CAP 定理最初是由加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在 2000 年的 ACM PODC 上提出的一个猜想，也因此被叫做布鲁尔定理。后来在 2002 年，麻省理工学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了 CAP 定理的证明，让它成为分布式系统领域公认的一个定理。 CAP 定理指出了，在一个跨区域网络连接，共享数据的分布式系统中，一致性（Consistency），可用性（Availability）和分区容错性（Partition Tolerance）

面对可能出现的网络延迟，不可预估的请求流量等情况，设计一个分布式系统，我们通常围绕系统高可用，数据一致性的目标去规划和实现，想要完全实现这个目标，却并非易事。由此，分布式系统领域诞生了一个基本定理，即 CAP 定理，用于指导分布式系统的设计，从系统高可用，数据一致性，网络容错三个角度将分布式系统的特性抽成一个分区容错一致性模型。这样一来，让系统设计者只需根据业务场景特点，进行权衡设计适合业务场景的分区容错一致性模型即可，很大程度简化了分布式系统设计的难度。 也因此，CAP 定理是架构师所必须要掌握的内容，它影响着架构师对分布式系统的技术选型，技术决策。既然如此重要，接下来，我们就一起学习下 CAP 定理吧。 什么是 CAP CAP 定理最初是由加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在 2000 年的 ACM PODC 上提出的一个猜想，也因此被叫做布鲁尔定理。后来在 2002 年，麻省理工学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了 CAP 定理的证明，让它成为分布式系统领域公认的一个定理。 CAP 定理指出了，在一个跨区域网络连接，共享数据的分布式系统中，一致性（Consistency），可用性（Availability）和分区容错性（Partition Tolerance）

2018 年夏天 国内微服务开源 领域，迎来了一位新成员。此后，在构建微服务注册中心和配置中心的过程中，国内开发者多了一个可信赖的选项。 Nacos 是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台( 官方网站 )，它凝聚了阿里巴巴十多年来在超大规模注册和配置上的最佳实践，可以用在微服务场景作为服务注册中心、配置中心等核心场景中，和阿里的其他微服务开源项目一样，Nacos 也是始于阿里，成长于社区的典型。 为什么要开源 Nacos ？ 在大规模服务发现和服务治理领域，现有的开源解决方案并非已经非常完美，阿里巴巴从 IOE 集中式应用架构升级为互联网分布式服务化架构的演进过程中，积累了大量有关服务注册和服务配置的实践经验，而这些经验是可以在各个行业大规模复用。除此之外，更重要的是，希望和社区开发者共同发展，让 Nacos 可以帮助国内企业更自由的构建基于云原生应用的动态服务发现、配置和服务管理。 相比其他服务注册和配置中心开源方案，Nacos 的起步虽然晚了点，但除了注册和配置中心的功能外，他还提供了动态服务发现、服务共享与管理的功能，在大规模场景下具备更优秀的性能，在易用性上更便捷，分布式部署上更灵活。例如和 Consul / Eureka / Zookeeper 相比：（内容摘自 《主流微服务注册中心浅析和对比》 ） Nacos Consul

一、MacVlan 实现Docker的跨主机网络通信的方案有很多，如之前博文中写到的通过 部署 Consul服务实现Docker容器跨主机通信 Macvlan工作原理： Macvlan是Linux内核支持的网络接口。要求的Linux内部版本是v3.9–3.19和4.0+； 通过为物理网卡创建Macvlan子接口，允许一块物理网卡拥有多个独立的MAC地址和IP地址。虚拟出来的子接口将直接暴露在相邻物理网络中。从外部看来，就像是把网线隔开多股，分别接受了不同的主机上一样； 物理网卡收到包后，会根据收到包的目的MAC地址判断这个包需要交给其中虚拟网卡。 当容器需要直连入物理网络时，可以使用Macvlan。Macvlan本身不创建网络，本质上首先使宿主机物理网卡工作在‘混杂模式’，这样物理网卡的MAC地址将会失效，所有二层网络中的流量物理网卡都能收到。接下来就是在这张物理网卡上创建虚拟网卡，并为虚拟网卡指定MAC地址，实现一卡多用，在物理网络看来，每张虚拟网卡都是一个单独的接口。 使用Macvlan注意： 容器直接连接物理网络，由物理网络负责分配IP地址，可能的结果是物理网络IP地址被耗尽，另一个后果是网络性能问题，物理网络中接入的主机变多，广播包占比快速升高而引起的网络性能下降问题； 宿主机上的某张网上需要工作在‘混乱模式’下； 前面说到，工作在混乱模式下的物理网卡，其MAC地址会失效

微服务 软件架构是一个包含各种组织的系统组织，这些组件包括Web服务器，应用服务器,数据库，存储，通讯层)，它们彼此或和环境存在关系。系统架构的目标是解决利益相关者的关注点。 什么是微服务架构 微服务架构优势 独立部署，由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。 技术选型灵活微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，当需要对技术栈进行升级时所面临的风险较低，甚至完全重构一个微服务也是可行的。 容错:当某个组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。 扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性,因为每个服务可以根据实际需求独立进行扩展。 高并发 1、应用缓存 2、HTTP缓存 3、多级缓存 4、池化 5、步并发 6、扩容 7、队列 Dubbo 1、服务集群