讨论主题之前看到一篇文章：关于物理看板VS电子看板的帖子，分析对比了两者的优劣势。最后作者给出建议：物理看板，比较适用于团队刚刚使用敏捷时。电子看板，比较适用于分散的分布式团队。那么，如果一个刚刚成立的分布式敏捷团队应该选择哪种看板呢？如果只想用一种避免维护上的浪费的话。个人观点个人一直以来都推崇物理看板，对于异式地分布式团队的站会，也是比较倾向于物理看板——盯着人看好过盯着电脑看。大家怎么看呢？

1、简介Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。与其他分布式服务注册与发现的方案，Consul的方案更“一站式”，内置了服务注册与发现框 架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如ZooKeeper等）。使用起来也较 为简单。Consul使用Go语言编写，因此具有天然可移植性(支持Linux、windows和Mac OS X)；安装包仅包含一个可执行文件，方便部署，与Docker等轻量级容器可无缝配合 。官方链接：https://www.consul.io  类别：用于实现分布式系统的服务发现与配置2、基础环境类别子项版本获取地址(方法)华为云虚拟机KC1（920）--OSCentOS7.5Kernel4.14软件包Consul0.9.2https://releases.hashicorp.com/consul/0.9.2/consul_0.9.2_linux_arm64.zip3、依赖安装无4、组件安装下载Consul二进制包：wget https://releases.hashicorp.com/consul/0.9.2/consul_0.9.2_linux_arm64.zip使用命令unzip命令解压包，并指定目录到/usr/local/bin: unzip consul_0.9.2_linux_arm64.zip -d /usr/local/bin/配置环境变量，保存后退出。vi /etc/profileexport CONSUL_HOME=/usr/local/bin/consulexport PATH=$PATH:CONSUL_HOMEsource /etc/profile查看是否安装成功：consul --version版本信息如下：5、系统配置   无6、测试 1）启动consul：# -dev表示开发模式运行，另外还有-server表示服务模式运行consul agent -dev 2）查看consul cluster中的每一个consul节点的信息：consul members   7、参考信息    无8、FAQ无

1、简介  Apache Slider目前还是Apache二级孵化项目，作为yarn的动态应用，可将已有分布式服务或者应用直接部署到YANR上，监控应用并按需调整应用资源大小。2、基础环境类别子项版本获取地址(方法)华为云虚拟机KC1（920）--OSCentOS7.5Kernel4.14软件包slider0.80https://archive.apache.org/dist/incubator/slider/0.80.0-incubating/slider-assembly-0.80.0-incubating-all.tar.gz 3、依赖安装环境中必须已经安装好hadoop以及jdk。安装方法可以看相应的安装手册。4、组件安装  下载slider并解压cd /usr/localwget https://archive.apache.org/dist/incubator/slider/0.80.0-incubating/slider-assembly-0.80.0-incubating-all.tar.gztar -zvxf slider-assembly-0.80.0-incubating-all.tar.gz解压后会生成一个slider-0.80.0-incubating文件夹此slider包不需要编译可以直接使用5、系统配置进入到解压目录的conf目录cd /usr/local/slider-0.80.0-incubating/conf我们需要修改两个文件，修改之前我们需要知道两个东西，一个是hadoop的安装路径、jdk的安装路径和自己的hostname。hadoop的安装路径我们可以find / -name hadoop 来确定，搜索结果里面有 /hadoop加版本号/etc/hadoop 这样显示的就是我们要找的路径。 jdk的安装路径及版本我们可以find / -name jdk*来确定 hostname可以通过查看/etc/hosts来确定，如果是分布式环境从机的名字也需要都记住。 确定这两个路径之后我们开始改两个文件，第一个文件slider-env.sh：加入vim slider-env.shexport JAVA_HOME= /opt/app/jdk1.8.0_212export HADOOP_CONF_DIR= /opt/app/hadoop-2.7.7/etc/hadoop 第二个文件slider-client.xml：加入以下内容，2181是slider默认的端口vim slider-client.xml<property>    <name>hadoop.registry.zk.quorum</name>    <value>master:2181</value></property> 假如你的是分布式的环境你需要把所有机器的名字都写上去。可以看下面的例子。 这两个文件配置完成后配置环境变量vim /etc/profileexport SLIDER_HOME=/usr/local/slider-0.80.0-incubatingexport PATH=$PATH:$SLIDER_HOME/binsource /etc/profile这些设置完成后可以slider version来查看是否安装成功看到以下表示安装成功；         6、测试无7、参考信息https://my.oschina.net/yulongblog/blog/7442558、FAQ无

1 cassandra简介Cassandra是一套开源分布式NoSQL数据库系统。它最初由Facebook开发，用于储存收件箱等简单格式数据，集GoogleBigTable的数据模型与Amazon Dynamo的完全分布式的架构于一身Facebook于2008将 Cassandra 开源，此后，由于Cassandra良好的可扩展性，被Digg、Twitter等知名Web 2.0网站所采纳，成为了一种流行的分布式结构化数据存储方案。2 环境信息2.1 环境信息类别子项版本获取地址OSCentOS7.5 Aarch64href="https://www.centos.org/download/" https://www.centos.org/download/服务器配置16U16GB40GB软件ant1.0.5http://apache.mirrors.spacedump.net//ant/source/apache-ant-1.10.6-src.tar.gzcommons-net4.0.9http://apache.mirrors.spacedump.net//commons/net/binaries/commons-net-3.6-bin.tar.gzjsch0.1.55 https://kent.dl.sourceforge.net/project/jsch/jsch.jar/0.1.55/jsch-0.1.55.jarxml-commons-resolve1.2http://apache.mirrors.spacedump.net//xerces/xml-commons/binaries/xml-commons-resolver-1.2.tar.gzjakarta-regexp1.5http://archive.apache.org/dist/jakarta/regexp/jakarta-regexp-1.5.tar.gzjakarta-oro2.0.8http://archive.apache.org/dist/jakarta/oro/jakarta-oro-2.0.8.tar.gzcassandra3.11.4https://github.com/apache/cassandra/archive/cassandra-3.11.4.tar.gz3 软件移植3.1 环境准备OS安装类型：CentOS-7.5-aarch64-1804。 注：操作系统安装使用最小简化版安装(如上图)，其余步骤安装一般安装操作系统步骤即可。 3.1.1 网络1、 安装cassandra安装需要maven下载依赖，需为服务器开通外网权限。3.1.2 相关软件下载上传2、 上传CentOS 7.5系统ISO镜像文件至服务器3、 添加用户并切换至cassandra用户useradd -d /usr/cassandra -m Cassandrapasswd Cassandrasu cassandra4、 下载并上传2.1环境信息表格中软件栏的所有源码包至服务器任意目录下,如/opt,：3.2 安装cassandra    1、 安装cassandra    上传以下脚本至要安装cassandra的服务器上的任意目录，如/opt。    （cassandra_install.sh）    添加执行权限：    chmod +x /opt/cassandra_install.sh    执行脚本    sh /opt/cassandra_install.sh    2、 提示cassandra install success表示安装成功。3.3 验证执行   1.启动cassandra，登录/cassandra/bin目录下执行./cassandra2.根据不同机型提示单线程最小内存栈大小修改配置文件，如上图本机所需最小328k，修改jvm.options，示例下图修改为329k  3.修改后再次启动cassandra，登录/cassandra/bin目录下执行./cassandra，如下图表示启动成功 4.另开一个窗口连接并测试下数据库  4 参考信息https://www.huaweicloud.com/kunpeng/software.html

1 Zookeeper简介Zookeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 2 环境信息2.1 环境信息类别子项版本获取地址OSCentOS7.5 Aarch64href="https://www.centos.org/download/" https://www.centos.org/download/服务器配置16U16GB50GB软件Zookeeper3.4.14 http://mirror.bit.edu.cn/apache/zookeeper/zookeeper-3.4.14/zookeeper-3.4.14.tar.gz3 软件移植3.1 环境准备OS安装类型：CentOS-7.5-aarch64-1804。 注：操作系统安装使用最小简化版安装(如上图)，其余步骤安装一般安装操作系统步骤即可。 3.1.1 相关软件下载上传1、 上传CentOS 7.5系统ISO镜像文件至服务器2、 上传zookeeper-3.4.14.tar.gz源码包至服务器目录下,如/opt下载地址：http://mirror.bit.edu.cn/apache/zookeeper/zookeeper-3.4.14/zookeeper-3.4.14.tar.gz 3.2 安装Zookeeper      1、 如果当前服务器没有网络，请先配置本地yum源。        a. 上传以下脚本至要安装Zookeeper的服务器上的任意目录，如/opt。        （local_yum_install.sh）        b. 执行如下命令添加执行权限：        chmod +x /opt/local_yum_install.sh        c. 执行如下命令安装配置本地yum源        sh /opt/local_yum_install.sh    2、 本地yum源安装完毕后，因为Zookeeper需要依赖java环境    yum install java-1.8.0-openjdk –y         3、 解压安装包     tar -zxvf zookeeper-3.4.14.tar.gz    cd zookeeper-3.4.14    4、 创建日志存放目录    mkdir dataDir    5、 拷贝样例文件为配置文件，准备修改    cd conf    cp zoo_sample.cfg zoo.cfg    6、 编辑配置文件，自定义日志存放目录，如下图    vim zoo.cfg     7、 启动Zookeeper  3.3 验证执行 

云数据库TaurusDB介绍页入口：cid:link_0云数据库TaurusDB帮助文档入口：cid:link_1 数据库的大家庭又有了一位重磅级成员——云数据库TaurusDB，它是华为自研的新一代企业级高扩展海量存储分布式数据库，兼容MySQL。既拥有商业数据库的高可用和高性能，又具备开源低成本效益。一起来认识下。       

前段时间，国际数据公司IDC发布了《2018年下半年中国企业团队协同软件市场跟踪报告》。报告显示，2018年下半年中国企业团队协同软件市场规模为8026.5万美元，同比增长23.8%。预测到2023年，中国企业团队协同软件市场规模将达到3.88亿美元，未来5年整体市场年复合增长率为23.1%。报告还指出，未来SaaS模式的企业团队协同软件的增速要远远高于传统部署模式，到2023年，SaaS模式的企业团队协同软件市场份额将从2018年的19.8%上升为31.8%。由此可见，企业协同软件市场的前景非常好，市场依旧不饱和，当然，市场竞争也愈加激烈。在这样的市场环境下，各厂商要实现自身的长足发展，必然要做出战略部署或改变，或强化产品、或加强渠道、或生态合作，总之，一定要有自己的核心竞争力。信核虽进入企业协同软件市场较晚，但企业文件共享云产品InfoShare一经发布便接受住了市场考验，它得到了用户的广泛认可，经过近两年的不断孵化升级，InfoShare给客户带来的服务半径越来越长，使用体验也越来越好。我们在增加使用场景的同时，保证产品操作简单，进而产生规模效应，帮助用户提高团队效率，应对数字化浪潮。InfoShare作为一款主打文件管理与协同办公的软件，它通过提供专业化解决方案来寻求差异化发展，进而获得竞争砝码。不同于传统的OA办公以及ERP软件，InfoShare侧重内容管理，进而实现对人的流程管理，而这正是协同的核心。下面，我们一起全面的了解下InfoShare，将它的核心功能点以及4.0版本的新功能一一列举来。01InfoShare主要功能模块文件管理01支持文件按使用场景分类管理（个人文件、部门文件、共享文件），支持对文件进行上传、删除、下载、修改等常用操作，支持文件夹上传以及拖拽上传，支持按关键字模糊搜索。共享管理02▷ 内部共享：支持将文件共享给指定用户，支持按需设置共享权限，共享访问权限细分至 7级，同时可设置拒绝权限，用户访问共享文件严格受到权限控制。▷ 外链共享：支持通过链接的方式共享文件与文件夹给外部用户，可设置密码、权限、到期时间。权限控制03通过 ACL（访问控制列表：允许或拒绝访问） 搭建 InfoShare 整体权限体系，管理员可对不同用户分配不同的使用权限，普通用户可设置文件共享权限。在线预览04支持主流文件格式如：Word、PPT、Excel、TXT、PDF、图片、CAD 等在线预览。消息管理05支持统一推送消息，包括账户变更、文档评论、评论回复、文件共享等，支持对消息进行管理，进行标为已读、删除等操作。用户组管理06用户组用于满足用户临时性的多人文件共享需求，用户可按需设置多个用户组，创建者拥有用户组的完全权限，可在添加、移除用户进用户组，编辑、删除用户组。日志系统07记录平台用户的文件变更操作以及登录 IP 信息，普通用户可查看本人操作日志，超级管理员可查看所有用户日志，可通过多种筛选方式进行日志查找执行日志审计。系统管理08▷ 用户管理：部门管理，注册管理，用户组管理，超级管理员可禁用或激活用户，可分配用户至相应部门，设置用户、部门配额，设置企业组织架构，分配部门负责人等；普通用户可管理用户组，删除，新建用户组。▷ 授权管理：提供试用授权以及永久授权两种模式，支持按用户数授权。▷ 系统设置：开启关闭水印、修改全局配额，分配超级权限。02InfoShare4.0新特性1分布式集群采用分布式集群架构，无论是 InfoShare 服务节点还是 InfoShare 存储节点均支持横向扩展，并且通过内部 LVS 实现实时负载均衡。节点扩展最多可达数十个。2支持多种存储类型存储端支持接入分布式文件系统或对象存储 ，适应多种用户场景。3SaaS 模式支持多租户模式。用户可以采用订阅的方式购买 InfoShare SaaS 服务，按需购买降低用户硬件服务器初始投入，更加灵活方便。4外链共享支持外链共享，可通过链接方式共享文件给外部用户，外链共享可设置访问权限、密码和到期时间。5文件秒传支持文件秒传，当上传的是重复文件时速度将快至秒级。6全局文件去重支持 InfoShare 系统全局文件去重，大幅节省存储空间。7web文件夹下载支持 web 端文件夹下载，文件管理更加便捷。8共享管理开放入口统一管理内部共享与外链共享出去的文件与文件夹。9本地同步本地同步将扩展 Windows 客户端使用范围，可以将任意位置的文件与InfoShare 云端文件进行同步，这样InfoShare 的使用范围即不局限于一个盘，而是能够有效扩展至多个盘，甚至整个 PC 电脑。10文件锁定支持文件独占锁定，当想要对文件进行在线编辑时，可主动锁定文件，此时其他用户将以只读模式打开文件，防止发生内容冲突，数据丢失。11本地预览支持当用户点击打开只有预览权限文件时，在本地打开预览窗口实现文件预览，兼顾了文件安全性与用户体验。12授权升级支持授权为两种使用模式，单租户的线下私有云模式，多租户的 SaaS平台模式。13界面UI改版界面交互与 UI 全新设计，交互逻辑更加简洁，美观度大幅提升。14手机客户端支持安卓、iOS 手机客户端，可便捷在手机上处理文件。虽然《报告》指出未来SaaS模式的企业团队协同软件的增速要远远高于传统部署模式，但传统部署的需求仍旧不可忽视。InfoShare4.0支持多租户模式，能够以SaaS方式对外提供企业云盘服务；也可以采用按需购买服务的方式使用InfoShare云端服务，降低企业初始服务器投入。任何企业要实现数字化转型，都需要把协同和业务的数据进行集成，而这种集成要“以人为中心”，对人、数据、组织赋能。InfoShare便是在满足这一要求的基础上去提供专业的产品和解决方案的。

引言在这篇文章中将从分析一个开源项目的可分布性入手，介绍如何使用AP&RP技术。这是一个关于分布式系统设计新手入门的系列文章中的第二篇。您可以点击下面链接找到第一篇文章。分布式系统设计新手入门---1，微服务的拆分I.          介绍在新手入门1中我们简要的介绍了AP&RP技术。为了充分展现这个技术带来的惊人效果，我在github.com上随机挑选了一个项目。这个项目是一个电商的开源项目，名称叫shop，作者为Manphil，项目地址为https://github.com/Manphil/shop。这里要向他及其所有开源作者表示感谢。如果没有他们的工作，我将需要耗费更多的时间来编写本章的实例。首先我要对这个项目做一个整体的技术介绍。这是一个使用JAVA语言开发的电商项目。开发环境为开发环境：IDEA、Tomcat8.5。使用的数据库为MySql。分为前端两个部分，前端使用Bootstrap以及JQuery，后端基于SpringMVC、Spring、MyBatis进行开发，使用Maven构建工程。因为我们只是分析服务端系统的可分布性，限于篇幅将略过项目的构建，调试以及前端的部分。虽然这个实例为JAVA语言，但本篇所介绍的技术同样适用于nodejs，C++，C等语言开发的服务端软件系统。II.        整体的产品功能及系统架构Shop并不是一个成熟的开源项目，很多功能处于开发过程中。通过对其分析产生了一些让我也感到惊讶的结论。我会在后面总结这些结论。shop项目主要分为两个大部分，第一部分为系统管理，第二部分为前端调用接口。其全部有11个产品功能组成。如图1所示Shop系统架构也较为简单，分为后端服务和数据库端。后端服务直接通过MyBatis中间件链接数据库。如图2所示在shop中有62个可以被调用的接口链接。也就是说整个系统是由62个任务所组成的。相对于比较成熟的电商项目有着上百个接口来说，shop是比较简单的。III.      分析任务1先假设shop可以通过MySql集群实现AP操作，那么我们只要对软件系统中的任务读写数据的情况进行分类既RP分析，就可以知道项目shop能否进行分布式操作。这里我们挑选shop中比较复杂的两个任务来介绍具体的分析过程。其中之一是/info/list，这个功能负责返回用户的订单信息。他位于shop/controller/front/CustomerController.java文件中。其源代码如下：    @RequestMapping("/info/list")     public String list(HttpServletRequest request,Model orderModel){         HttpSession session=request.getSession();         User user;         user=(User)session.getAttribute("user");           if (user==null)         {             return "redirect:/login";         }           OrderExample orderExample=new OrderExample();        orderExample.or().andUseridEqualTo(user.getUserid());         List<Order> orderList=orderService.selectOrderByExample(orderExample);         orderModel.addAttribute("orderList",orderList);         Order order;         OrderItem orderItem;         List<OrderItem> orderItemList=new ArrayList<>();         Goods goods;         Address address;        for (Integer i=0;i<orderList.size();i++)        {            order=orderList.get(i);            OrderItemExample orderItemExample=new OrderItemExample();            orderItemExample.or().andOrderidEqualTo(order.getOrderid());            orderItemList=orderService.getOrderItemByExample(orderItemExample);            List<Goods> goodsList=new ArrayList<>();            List<Integer> goodsIdList=new ArrayList<>();            for (Integer j=0;j<orderItemList.size();j++)            {                orderItem=orderItemList.get(j);                goodsIdList.add(orderItem.getGoodsid());            }            Good**ample good**ample=new Good**ample();            good**ample.or().andGoodsidIn(goodsIdList);            goodsList=goodsService.selectByExample(good**ample);            order.setGoodsInfo(goodsList);            address=addressService.selectByPrimaryKey(order.getAddressid());            order.setAddress(address);            orderList.set(i,order);        }        orderModel.addAttribute("orderList",orderList);        return "list";     }1, “@RequestMapping("/info/list")”表示uri的链接/info/list将会触发调用函数“public String list(HttpServletRequest request,Model orderModel)”。这个调用并没有传递参数到函数中。它被触发的形式可能为http://localhost/info/list。2, 在“HttpSession session=request.getSession();”中首先读取了session的数据。Session内保存了当前链接关于安全和权限的数据。这段代码是检验只允许已经登陆的用户才能使用这个接口。注意session中的数据作为全局数据也是我们要分析的数据之一。3, 在“List<Order> orderList=orderService.selectOrderByExample(orderExample);”中读取了指定用户的所有订单的数据。其中“orderService.selectOrderByExample”最终被转换为mysql数据库的查询操作。4, 在获取了用户全部订单信息后，通过语句“orderItemList=orderService.getOrderItemByExample(orderItemExample);”查询具体订单中的物品信息。5，在“goodsList=goodsService.selectByExample(good**ample);”中查询物品的商品信息。6,　以及在address=addressService.selectByPrimaryKey(order.getAddressid());查询对应订单的地址信息。以上5个信息分别存储在数据库中的`address`，`indent` ，`orderitem`，`goods`以及全局数据session中。这里是以整个表为读取数据的使用范围。请注意这里的使用数据的范围。以读取用户全部订单为例，其使用数据的范围为整个`indent`表。得到的数据是用户的当前订单。这里以使用数据范围为边界而不是以得到的数据范围为边界。通过以上分析我们得到了“/info/list”的使用数据的范围并记录下来。如图3所示IV.      分析任务2我以“/orderFinish”来分析有写入数据的情况。“/orderFinish”的功能是将购物车的数据提交为订单。其代码如下    @RequestMapping("/orderFinish")     @ResponseBody     public Msg orderFinish(Float oldPrice, Float newPrice, Boolean isPay, Integer addressid,HttpSession session) {         User user = (User) session.getAttribute("user");           //获取订单信息         ShopCartExample shopCartExample = new ShopCartExample();         shopCartExample.or().andUseridEqualTo(user.getUserid());         List<ShopCart> shopCart = shopCartService.selectByExample(shopCartExample);           //删除购物车         for (ShopCart cart : shopCart) {             shopCartService.deleteByKey(new ShopCartKey(cart.getUserid(),cart.getGoodsid()));         }           //把订单信息写入数据库         Order order = new Order(null, user.getUserid(), new Date(), oldPrice, newPrice, isPay, false, false, false, addressid,null,null);         orderService.insertOrder(order);         //**的订单号         Integer orderId = order.getOrderid();           //把订单项写入orderitem表中         for (ShopCart cart : shopCart) {             orderService.insertOrderItem(new OrderItem(null, orderId, cart.getGoodsid(), cart.getGoodsnum()));         }           return Msg.success("购买成功");     }1, 首先“@RequestMapping("/orderFinish")”将uri映射到了orderFinish函数。并传入了5个参数。这5个参数是前端调用uri时同时传入的。2, 在第一句中“User user = (User) session.getAttribute("user");”通过session获得了当前用户信息。3, 在“List<ShopCart> shopCart = shopCartService.selectByExample(shopCartExample);”中获得了数据库内的用户购物车信息。4, 在“shopCartService.deleteByKey(new ShopCartKey(cart.getUserid(),cart.getGoodsid()));”中删除了数据库内的购物车信息。5, 在“orderService.insertOrder(order);”将购物车的数据转为订单并提交到订单数据库。6，在“orderService.insertOrderItem”中将订单中的物品提交到了数据库中的“orderitem”数据表。通过对上述写入和读取数据范围的分析可知。“/orderFinish”读取了`shopcart`表和“session”中的数据。其读取范围为`shopcart`表和全部“session”。写入了`shopcart`，`indent`  ，`orderitem`共3个数据库中的表。其写入数据的边界同样为这3个表的全部。注意这里是**数据而不是更新数据。如果是更新数据，其更新的范围会更小。我们将在后续的章节里进一步讨论其中的细微差别。同样将我们的分析结果记录下来如图4所示V.        工程的可分布性当我们把所有的任务读取和写入的数据都整理好以后放入表格文件（见附件）。我们发现在这个工程中只有少数操作使用数据库字段。大部分数据都是以表为单位使用全部数据字段。在项目中无效的任务为6个。有读取数据的任务为28个。有写入数据的任务有30个。写入数据之间没有原子关系的任务为1个。有原子关系的任务共29个分为8组。除去无效任务剩余的37组任务可以分布到37个服务器容器中。整体工程的可分布性比率即可分布任务组与有效任务之比为69.3%。如图5所示其中任务有原子关系是指读取的数据之间有写入冲突只能放在有原子性的服务器容器内。在30个有写入数据的任务中，有29个任务有原子关系共分为8组。例如“/addCategoryResult”，“/saveCate”，“/deleteCate”都写入表`category`。所以这3个任务具有原子关系，被分为一组。这8组写入任务最多只能放在8个有原子属性的服务器容器内。也就是8个单线程的服务器容器。对于其余的28个只读任务，在前面已经假定我们使用的是分布式数据库集群来模拟AP技术。这种数据库集群可以使用Oracle, HP vertica, SAP HANA或OceanBase，以上是世界知名公司的产品，不需要我来打广告。虽然使用数据库集群模拟的AP操作效率较低，但为了更方便初学者我们使用数据库集群来替代AP操作，以后的章节里我们会学习如何手动进行AP操作。这里先假定数据库集群可以为每个任务提供一个额外的服务器节点用于处理AP操作。那么这个项目在一般情况下最大可以分布到74台服务器集群中。VI.      一般分布式方法让我非常惊讶的事情在于一个电商网站的工程离散性居然如此之高。在没有使用任何其他特殊技术的情况下只是引入了数据库集群。并且没有修改任何代码的情况下就将服务器扩张了74倍。如果按传统的产品功能分割的方法则最多只能分为11个部分。而且要非常耗时耗力的分割软件工程和分割数据库。这里我将这种分布式技术的一般应用称为一般分布式技术。一般分布式技术是在最小改动工程的基础上运用分布式技术进行系统分布式的方法。与此相对而言，AP&RP技术绝不仅仅限于此。在使用一般分布式方法处理后的工程，我们会得到一个关于任务uri影射表的。以此项目为例可以简单的将服务端软件复制37份并放入37个服务器容器内。并使用nginx反向代理将uri影射到不同的服务器容器内。注意这里并不需要你去拆分软件工程。只要让不同的服务器容器处理不同的请求就可以了。例如我们配置其中一个服务器容器192.168.1.1用于处理`category`表的写入请求。前面得知“/addCategoryResult”，“/saveCate”，“/deleteCate”三个任务会写入`category`所以添加配置到nginx如下： location /addCategoryResult {         proxy_pass http:// 192.168.1.1:8080;     } location /saveCate {         proxy_pass http:// 192.168.1.1:8080;     } location /deleteCate {         proxy_pass http:// 192.168.1.1:8080;     } 将反向代理和数据库集群以及37个服务器的复制品放在一起，我们得到被分布式后的shop工程。如图6所示VII.    一些知识点与问题1，  AP&RP技术是否安全可靠？首先AP&RP技术没有修改您的任何业务逻辑。也没有增加任何额外的业务及硬件层级。所以不存在AP&RP技术失效导致系统停用的问题。在一般分布式技术中，从直观角度说由单台服务器扩张到多台服务器后。其中任何服务器的失效都不会导致集群整体业务的停止。所以这种扩展是对集群安全性的提升。现有的分布式方法是否更加安全呢？建议你去读FLP定理的相关论文。分布式系统不会比硬件带来更多的可靠性。这里向为我们提供了更多可靠性而不断努力的硬件工程师致敬。2，  谬误1，在不同功能分类中不存在有原子关系的任务。因为功能分类的划分是主观而随意的。常常会将一些有原子关系的任务划分到不同的功能中。例如示例中活动商品管理中的任务“/update”需要设置“goods(activityId)”与商品管理功能产生了原子关系。将这个任务与其他具有原子关系的任务放在一起，在分割中会更为自然。这里应将“/update”放入到商品管理中，这样做从产品设计的角度就显得有些奇怪。3，  谬误2，按功能分类不出问题但不代表正确。目前绝大多数分布式系统都是按功能进行划分的。然后工程师依据是否出现问题去修正系统。虽然大部分按功能划分的系统都运行良好。但我思考这也仅仅是运行良好而以。因为刚好没有触发RP冲突也就是原子关系的冲突。在一定概率上运行良好就认为这样划分没有问题，这是非常危险和不严谨的态度。4，  过度分层导致心智负担严重。软件功能过多的分层和硬件系统过多的分层对开发人员导致了严重的心智负担。仅仅为了阅读看起来更有层次而产生的分层。将软件真实处理过程与触发点严重分割开来。导致对软件的阅读产生了极大的障碍。例如本示例从触发数据库操作到真实调用数据库之间要跳转3个文件。而且作者额外开发了大量最终没有使用的数据库调用方法。这都导致了开发效率下降和开发成本增加。5，  有弹性的分布式系统。随着软件系统的访问流量的增长，系统拆分的越来越细是必然需求，但随着拆分的越来越细，工程的复杂度也会越来越高。当复杂度超过人脑在有限时间范围内能够理解的程度时，就需要计算机系统有能够按规则自动完成分解系统的能力。显然在处理极度复杂的系统时不能再单纯的依靠人力。因为人力管理本身就是极其不可靠和复杂的。我们需要更有弹性的自动化分布式系统。今后的章节里我们将会讨论更多的技术细节并最终完成一个有弹性的自动化分布式系统。6，  从面向计算到异步网络的延伸。分布式这门学科创建之初主要是为了解决数学计算能否分解的难题。例如能否用分布式的方法逆向hash算法。那时计算机还只是作为计算的工具。而此时计算机系统更像是人类社会中某个工具的延伸。你可以当它是商店，停车场收费器，外卖的呼叫器。人类网络本身就是一个大型的异步系统。当这种异步系统延伸到计算机系统时，计算机系统只是延续了人类这个异步系统的高离散性。这种离散性便是能否进行分布式及其边界划分的基础。我们也会花更多的时间来讨论分布式技术在学术上的意义。VIII.  感谢首先这里我想感谢我的妻子在我进行学术研究的这一年里对我的支持。也要感谢华为云网站和编辑。更要感谢您抽出宝贵时间进行阅读。希望我的文章能够帮助您学习了解分布式技术，并将AP&RP技术应用到您的网站设计中。现在您就可以动起手来看看您网站的可分布性啦？

3月30日，由中国 MySQL 用户组主办的ACMUG 全国巡讲深圳站圆满结束，华为云新一代企业级分布式数据库 Taurus 亮相技术峰会，其一系列高精尖特性背后的设计理念和技术原理也在外界的期盼中徐徐展现。Taurus 是华为云自研的最新一代云原生分布式数据库，完全兼容 MySQL 8.0，采用计算与存储分离、日志即数据的架构设计，支持1写15读，性能达到原生 MySQL 的7倍。此外，Taurus 构建在共享分布式存储上，存储空间最高达128T，能跨 AZ 部署。纵观业界，华为云Taurus 无论是功能还是性能，均走在了数据库领域的最前沿。那么，Taurus又是如何推陈出新一步步走到今天的呢？云上 MySQL 架构的不足当前，对于RDS for MySQL，各大云厂商基本都采用主备高可用模式、主备间使用Binlog复制（有些厂商采用DRBD），该架构下每添加一个从库都需要全栈式资源。这导致了一些问题：1. 资源浪费备库往往不承担流量；复制线程会消耗主库/从库计算资源，造成计算资源浪费；EVS的 3 副本冗余机制下，最大需要3*(N+1)个副本，造成存储资源浪费；以及多种数据需要走存储网络进行刷盘，造成网络资源浪费等。2. 扩展性不佳添加只读时需要拷贝数据，重放binlog，对于大数据量情况下速度很慢，尤其是采用本地盘方案。主从复制延迟问题会让主备倒换受影响，难于保证RTO。此外，采用物理备份、逻辑备份时备份恢复速度很慢， 1T以上数据量都以小时计，使得数据库扩展性受限。数据库作为承载业务和应用的核心所在，提供高扩展、高性能、高可用的分布式服务日渐成为用户刚需。如何兼容MySQL生态、对原有MySQL 应用无需任何改造就能轻松迁移？如何存储互联网业务下的海量数据？如何保障无缝弹性扩容、高可用、高并发性能？而现在，这些问题都找了答案。华为云 Taurus 分布式架构满足用户数据库高要求华为云的宗旨一向是想客户之所想，急客户之所需，华为云数据库 Taurus 也正是在这样的背景下诞生。架构上，Taurus 采用计算与存储分离，日志即数据，将IO 密集型负载卸载到存储节点完成。Taurus 还充分利用云存储的能力，实现存储层实现独立容错和自愈服务和共享访问(单写多读)。此外，Taurus还采用软硬件结合，充分利用RDMA网络、NVME SSD等硬件优势，对内核进行深度优化，使性能有大幅提升。对于大量对数据库有高要求的行业而言，华为云Taurus 的推出无异于“雪中送炭”。不但性能强悍，而且数据安全可靠、业务有保障，可广泛应用于下面的应用场景。 强悍性能支撑业务拓展随着 SaaS 应用在企业级市场的切入，高吞吐和高性价比随之成为大型互联网公司、传统大企业对数据库的要求。一方面，庞大的业务和高吞吐量使得开源库无法解决数据处理问题，另一方面，SQL Server、Oracle 等商用数据库的 license费用也成为企业高成本的一大忧患。Taurus 具有 RDMA、V5CPU、Optane等硬件优势和数据库逻辑下推、释放算力、减少网络开销的架构优势，完全兼容 MySQL 8.0 并提供7倍于原生 MySQL 的性能，对用户而言不用改造业务就能充分享受超高性能的数据库服务。且成本只有商用数据库的1/10。极致可靠助力金融行业实现数据0丢失故障闪恢复受监管诉求驱动，可靠性和可用性是金融行业的核心诉求。第一要务是数据不能丢，其次是故障秒级恢复。但传统MySQL 并不能支持此高要求。Taurus 的共享存储架构，将数据持久化放入新一代存储中，充分保障数据强一致性和0丢失。Taurus的存储3副本容错能力，使得数据库的单点故障0中断得以实现，加之对跨AZ 部署和跨 Region 容灾的支持，让计算节点故障秒级恢复不再是难题。多维扩展和海量存储满足游戏行业高速发展需求轻资产，快速扩容作为游戏行业使用云数据库驱动力，其主要目标在于解决无法预测用户流量以及产生的数据量、业务高峰时用户体验会受到影响甚至要停服扩容的问题。Taurus 基于云虚拟化，单节点可规格变更，且计算节点支持双向扩展，支持1写15读，扩展比达0.9。此外数据存储池化后最大可支持128TB容量，且存储按需计费, 扩容不中断业务，计算节点扩容也不会带来存储成本上升。Taurus 的愿望很简单，希望用户同时享受商业级的技术服务和开源软件的生态红利。想了解更多信息，请扫码关注【HW云数据库】

尊敬的华为云客户：华为云计划于2019/04/01 00:00（北京时间）将分布式缓存服务Redis标准版4.0及5.0版本正式转商用。商用后，服务会按功能类型、性能规格和使用时长计费，具体价格请届时参考该服务的计费详情页。如果需要继续使用分布式缓存服务Redis标准版4.0及5.0版本，请提前确保账户余额充足，华为云在此提醒您，相关资源如果不再使用，请于2019/04/01 00:00（北京时间）前登陆控制台，删除对应资源，避免产生费用。更多关于分布式缓存服务Redis的产品介绍，请您点击了解。如您在使用过程中有宝贵意见，欢迎您拨打华为云服务热线:4000-955-988与我们联系。感谢您对华为云的支持！https://www.huaweicloud.com/notice/2018/20190326170621750.html

3月22日， 2019 华为生态大会在福州圆满落幕。本次大会上，华为云发布了两款具有划时代意义的云数据库产品：最新一代企业级高扩展海量存储分布式数据库Taurus，和全球化的 NoSQL 分布式多模数据库Gemini。二者均为华为云厚积薄发的自研产品，针对用户普遍需求，结合当下云数据库领域最新技术，在功能和性能方面都有大幅提升。十年磨一剑：华为云自研云上企业级融合分布式数据库发布新一代企业级高扩展海量存储数据库 Taurus绝大部分企业在数据库选择方面，都曾面临一个难题：开源还是商业？商业级数据库性能好，可靠性高，数据库厂商提供数据库维护，但成本高、生态不开放。大型企业每年支出的Lisence 和运维费用高达千万，中小企业基本无法负担。此外应用被数据库绑定，要迁移到别的生态就得改应用，改造成本相当之高。开源数据库可免费使用、用户量大生态广阔，但可靠性差、安全性、性能都较差，且维护成本高。开源数据库需要专业的DBA 人才团队来运维，并且高可用方案尚不完善，容易出现丢数据、故障恢复时间长等问题。此外，面对互联网上的攻击，企业需要投入额外的成本做安全防护，出了问题也只能依赖社区，效率得不到保障。那么，有没有同时结合了商业数据库和开源数据库两者优势的数据库呢？华为云数据库Taurus 就是最佳答案。1极致可靠华为云 Taurus 采用存储与计算分离的新型架构，提供跨3个城市的数据副本，将备份数据保存至OBS（对象存储服务），数据可靠性高达11个9（99.99999999%），绝无数据丢失的担忧。此外通过数据分片技术，Taurus能实现秒级恢复存储故障，软件故障恢复则可保障业务不中断和数据0丢失。小到软/硬件故障，大到自然灾害，都有自动化快速恢复方案。 2极致性价比华为云 Taurus 的单节点性能最大可达原生 MySQL的7倍；同时通过只读扩展，读性能可以成倍线性提升，业界同类产品无与争锋。在同等规模下，Taurus成本只有商业数据库的1/10，且提供整套数据库运维服务，可大大减少企业人力投入。 3多维扩展Taurus 集群规模高达1写15读，其中只读节点企业可以根据业务需要在线动态扩展/收缩，无论是CPU、内存、还是数据库节点，都能够简便地一键扩展，方便快捷。Taurus还会根据用户存储容量自动扩容，存储空间最大可达 128TB，且扩容期间不会对业务造成任何影响，消除了运维人员通宵部署硬件之苦。 4完全可信Taurus通过与DBSS（数据库安全服务）的透明化集成，不用修改应用，只需在界面配置即可享受智能化的安全保障，可以防御各种互联网攻击，防护数据泄露。 当前，华为云数据库已通过可信云认证，提供国际级的隐私和数据保护。值得一提的是，Taurus 完全兼容MySQL8.0 版本，用户可以将原有的 MySQL 线下业务无缝迁移上云，不用担心额外业务改造成本。后续，华为云将在持续优化Taurus 性能和功能的基础上，同步社区更新，使用户在技术上同时享受商业级的技术服务，和开源软件的生态红利。 全球化的分布式多模数据库 GeminiGemini 是一款华为自研的旗舰级、CloudNative架构、Serverless 按需弹性伸缩、跨Region容灾、自驱动的、多模 NoSQL 云数据库服务产品。其兼容支持多种主流NoSQL生态/接口模型，包括 MongoDB、Cassandra和 DynamoDB 等。1 3倍性价Gemini 在社区版的相同配置情况下，能达到 3 倍性能提升。Gemini具备业界领先的Serverless特性，即根据吞吐量需求自动的弹性伸缩，为客户节省大量成本。2 企业级可靠性Gemini 具备企业级的数据可靠性，能够容忍N-1个节点故障，并且在节点故障时对客户的应用无感知，不影响数据的读写。通过多节点并行的快照备份，做到10 倍以上的备份恢复性能提升，20分钟内能够完成任意时间点的恢复。3 灵活全托管Gemini 基于业界领先的计算存储分离架构模式，灵活性能够达到同类产品百倍。此外它在内核层面做到实时监控实例的数据存储量以及吞吐量，一旦达到扩容阈值，在2分钟内能够自动扩展完成，让用户可以放心托管数据库。4 完善的数据库生态Gemini 具备完善的数据库生态体系，有DAS作为图形化的数据编辑工具，有DRS支持数据的在线迁移、同步和跨版本的复制，有云DBA作为自动化的数据库诊断工具，并且能够与大数据组件无缝对接。Gemini 的特性使其非常适用于游戏、工业制造、互联网等行业。游戏具有快速迭代、开服吞吐量高峰、快速开服、全球同服、降成本、附近玩家、回档等行业关键需求，在Gemini下都能够很好地支持。工业制造、互联网行业需要存储海量数据，Gemini 能很好的支持7*24小时实时高并发数据写入，作业高峰期弹性扩展。华为云 Gemini 将在全球布局规划，让每个 Region间数据实时进行超低时延的同步，帮客户业务实现全球容灾和就近读写。轻松上云：华为云DRS实现多场景数据迁移作为核心业务运行的主要承载体，数据库上云一直是客户最关心的问题之一。如何保障迁移时核心业务不中断？如何确保数据不丢失？数据库迁移实施难度大、没有专家团队怎么办？华为云数据复制服务DRS正是为了解决这些问题而推出。华为云 DRS 是一种易用、稳定、高效，用于数据库在线迁移和数据库实时同步的云服务，业内首家提供数据预估功能、参数迁移、用户迁移，并通过多项核心技术，让RPO&RTO双控在秒级，数据库异地灾备的业界最高水平，完美解决跨云灾备、本地到云灾备、混合云灾备、跨区云灾备等场景下的能力空白。DRS 的引导式操作、近百项检查、详细的指导让没有迁移经验的用户也能做好迁移。此外通过在线迁移技术和数据实时同步，能确保数据库迁移上云业务中断时间最小化。DRS的断点续传、故障重试、迁移后对象、数据对比等多项特性组合，实现迁移任务高效、无死角，数据 0 丢失的完成。当前，DRS 支持多来源、多网络、多引擎迁移。无论用户是从本地机房、其他云、华为云内部，采用公网网络、华为VPN网络、专线网络、华为VPC网络，均可对MySQL、SQL Server、PostgreSQL任意一款数据库进行迁移。云开年采购季火热进行中！免费抽奖，人人有礼，消费满额送mate20，爆款数据库低至5.8 折 火热抢购，了解详情，请点击下面链接。https://activity.huaweicloud.com/2019Feb-promotion/index.html?utm_source=wechat&utm_medium=officialaccount&utm_campaign=2019feb_promotion_0322&utm_content=sjk_xcp

华为云IoT平台增强版和基础版均支持对接分布式消息服务DMS，开发者平台暂时不支持对接DMS调测，本节使用IoT平台基础版对接DMS进行测试。创建DMS队列操作步骤登录华为云-->进入控制台-->搜索DMS并进入DMS服务控制台-->创建队列在平台配置DMS服务认证信息AK/SK①获取AK/SK在公有云基本信息 > 我的凭证 > 管理访问密钥 中新增访问密钥，成功后将下载一个credentials.csv文件，文件中包含AK和SK②将AK/SK配置到IoT平台    规则引擎 > 创建规则 中配置规则引擎至此，DIS服务已配置完成，可以开始使用设备上报数据进行测试了在DMS控制台查看数据如图，监控图表中显示有数据，即表示数据已抵达DMS服务调用DMS接口获取数据详情请参考：分布式消息服务DMS API参考

我们知道每个pod内都会有一个Envoy容器，其具备对流入和流出pod的流量进行管理，认证，控制的能力。Mixer则主要负责访问控制和遥测信息收集。如拓扑图所示，当某个服务被请求时，首先会请求istio-policy服务，来判定是否具备访问资格，若具备资格则放行反之则请求不会被下发到服务。这一切的访问信息，都会被记录在Envoy中，之后会上报给mixer作为原始数据。遥测数据的收集及其他功能完全是灵活可控的，你既可以配置新的收集指标和日志，也可以完全禁用这些功能。1.Prometheus的应用和指标介绍Prometheus是一款开源的监控和告警系统，2016年加入CNCF，以其灵活的检索语言，高效的数据存储方式以及多维度的数据模型使得越来越多的人使用。Istio自0.8开始就默认的将Prometheus包含在内，我们可以通过查询service或者pod看到普罗的运行状态和地址。点开Prometheus界面，UI十分简洁明了。用户在Expression内输入想要查询数据的表达式，并且再输入的过程中，普罗还会在已有的指标中做出提示方便用户查找。我们输入一个简单的查询表达式istio_requests_total,点击Execute，在图形界面中，将鼠标放到图中的折线可以看到请求的详细信息。 详细信息中的每一项都可以作为选定参考指标的特性，例如我们需要查询返回值为200的productpage请求总数，就可以在之前的表达式中添加大括号和限定条件。Istio支持和允许用户自己定义新的遥测数据，并且在官网->任务->遥测->收集指标和日志中有详细的描述。用户可以自定义需要的监控指标进而可以再普罗查看监控数据结果。2.Jaeger UI的使用和介绍Istio配合jaeger可以解决端到端的分布式追踪问题。Jaeger于2017年9月成为CNCF的成员。Jaeger是一款开源的分布式追踪系统，由Google Dapper和OpenZipkin社区联合推动。Jager主要可以使用在微服务的架构上来完成分布式上下文广播，分布式事务监控，根因分析，服务依赖关系分析，性能/延迟优化等功能。Jaeger的界面极其简洁，在首页面选择你想了解的服务（productpage）以及选择你想观测的时间范围（过去两天），而后点击find trace按钮，页面就会显示过去两天内访问productpage的所有trace。点击trace的名字，则会跳转到详情界面。 这个界面中你可以看到每个请求可能会分为不止一个的子请求，以及这个请求的处理时间。例如我们访问productpage，productpage会请求details和reviews这两个服务，那么初始的请求就会分为两个子请求，一个请求details的内容另一个请求reviews的内容。Details部分的请求总耗时4.99ms，reviews部分的请求耗时5.61ms。内容返回并处理后，整个productpage的请求耗时21.32ms。这个详情界面不仅会体现每个请求的耗时也反映服务之间的调用关系。根据istio官方给出的解释，我们知道istio proxy根据http部分headers来归纳和合并请求的。对于一个结构复杂，流量庞大的服务网格，追踪所有的调用不但不利于收集有效数据，还会造成冗余，浪费资源等问题，所以在制定监控服务的时候也需要去设定其采样频率。对于Bookinfo这种示例型应用，我们的采样率可以设的高一点，对于大型应用就要进行适当的降低。调整采样率一共有两种方式。•在创建服务网格之前，我们可以提前设定好采样频率，在Helm模板的values.yaml文件中，pilot内的traceSampling属性可以对采样频率进行修改。 打开istio/chart/pilot/templates/deployment.yaml可以看到一个简单的赋值过程。•正在运行的服务网格，对deployment istio-pilot进行编辑。首先查看所有的deployment：然后对其进行编辑，搜索PILOT_TRACE_SAMPLING这个属性，并对其值进行修改：我们先打开jaeger UI确定过去一个小时没有任何对productpage的访问。 而后将PILOT_TRACE_SAMPLING的值从原有的100改为50。修改并保存后会有提示信息显示istio-pilot已经被修改。 稍等片刻后，我们使用脚本curl productpage10次。再次在jaeger UI上选择productpage选择过去一小时，点击Find Trace，会发现这次只检测到4个trace。我们在用相同的脚本再运行一次，发现检测到10个trace。至此我们一共curl product page 20次总共获得10次 trace，符合总次数的50%。现在我们用相同的方法，将PILOT_TRACE_SAMPLING改为100%并且稍等片刻。使用相同的脚本curl10次product page，再点击Find trace，现在总共有20个Trace，也就是先前的10个trace加上后来curl的10次，证明 PILOT_TRACE_SAMPLING修改完毕会采集所有的请求。3.华为云istio服务中简明监控介绍在组件详情界面中除去CPU使用率，内存使用这种基本的监控外，华为云提供了另外两项简明流量监控，分别是RPS(平均处理请求次数)和RT（平均响应时延）。RPS以分钟基本时间单位，纵轴则以处理请求次数为单位，用户可以直观的看到自己的应用单位时间内需要处理的请求数量。若RPS过高，则用户可以适当的采用相应措施，报障请求的高效处理。 RT也是以分钟为单位，但是纵轴则是该时间段内平均的请求响应时间。如果个别时间段请求时延过高，用户则需要对自己服务进行分析。 组件详情这个界面更多的还是提供一个粗粒度的流量监控，将应用的工作关键信息最直接，最明确的呈现给用户。方便用户对自己的应用，资源，服务规划进行调整和改进。在今后，华为云会提供维度更多的监控，分析等服务。Istio提供很多即插即用的服务，用户不需要修改自己的代码，也不需要重新构建自己的应用便可以直接享用istio带来的“红利”。可视化的监控服务，可修改的监控内容，可以更好地让用户了解自己应用的工作状态。本文只介绍了入门级的istio监控内容，除上文内容外，监控服务还有更多的功能等待用户去研究和使用。Istio就像一座金矿，而金子只属于勤奋的淘金工人。

本文内容：    使用mesher对服务进行sidecar模式的代理，并结合zipkin实现对服务的分布式追踪。需求背景：    client ---> mesher_client --->mesher_server_A --->server_A --->mesher_server_A --->mesher_server_B--->server_B在此需求背景下，我们希望该请求以一条完整的调用链进行显示，而不是分成client --server_A 和server_A -->server_B两条调用链显示。环境准备（这里只演示本地）：1，一个华为云账号，并下载mesher下载2，zipkin下载 3, local-service-center 下载    步骤：1，部署zipkin，本文不详细介绍zipkin部署,可参考zipkin。2 运行server_B及mesher_B2.1  配置microservice.yamlAPPLICATION_ID: mesher service_description:     name: server_B # 服务名     version: 1.0 # 服务版本2.2 配置chassis.yaml--- cse:   protocols:     http:       listenAddress: 192.168.0.131:30112 #监听地址，外部地址   service:     registry:       address:  https://cse.cn-north-1.myhuaweicloud.com:443 #如为local-sc请配置为http://127.0.0.1:30100  handler:     chain:       Consumer:  #consumer handlers       Provider:         incoming: tracing-provider,transport    tracing:  enabled: true   collectorType: zipkin  collectorTarget: http://localhost:9411/api/v1/spans #zipkin aderss2.3 配置auth.yamlcse:   credentials:     accessKey: *** # you ak     secretKey: *** # you sk注：ak/sk获取请参考这里，该配置不区分consumer或provider，配置都是相同。如使用local-service-center部署，则不需要该配置2.4 配置环境变量SPECIFIC_ADDRexport SPECIFIC_ADDR=127.0.0.1:82 #用于设置mesher的后端服务地址，即server_B监听地址注：此处请根据本身服务监听地址进行修改2.5 启动mesher./mesher2.6 启动server_B请根据自己本身开发的server_B进行启动，此处需要注意的是，在启动server_B之前需要设置环境变量http_proxy或HTTP_PROXY，该环境变量设置的值为该服务的代理mesher监听地址，在以上配置中http_proxy应设置为export http_proxy=http://192.168.0.131:301123 运行server_A及mesher_A3.1  配置microservice.yamlAPPLICATION_ID: mesher service_description:     name: server_A # 服务名     version: 1.0 # 服务版本3.2 配置chassis.yaml--- cse:   protocols:     http:       listenAddress: 192.168.0.131:30111 #监听地址，外部地址   service:     registry:       address: https://cse.cn-north-1.myhuaweicloud.com:443 #如为local-sc请配置为http://127.0.0.1:30100  handler:     chain:       Consumer:          outgoing: loadbalance,tracing-consumer,transport       Provider:         incoming: tracing-provider,transport   tracing:  enabled: true   collectorType: zipkin  collectorTarget: http://localhost:9411/api/v1/spans #zipkin aderss3.3 配置auth.yaml    请参考 2.33.4 配置环境变量SPECIFIC_ADDRexport SPECIFIC_ADDR=127.0.0.1:81 #用于设置mesher的后端服务地址，即server_A监听地址3.5 启动mesher./mesher3.6 启动server_A此处和启动server_B之前一样，同样需要设置环境变量http_proxy或HTTP_PROXY，详细参考 2.6.4  运行client及mesher_client4.1  配置microservice.yamlAPPLICATION_ID: mesher service_description:     name: client # 服务名     version: 1.0 # 服务版本4.2配置chassis.yaml--- cse:   protocols:     http:       listenAddress: 192.168.0.131:30111 #监听地址，外部地址   service:     registry:       address: https://cse.cn-north-1.myhuaweicloud.com:443  #如为local-sc请配置为http://127.0.0.1:30100   handler:     chain:       Consumer:          outgoing: loadbalance,tracing-consumer,transport tracing:  enabled: true   collectorType: zipkin  collectorTarget: http://localhost:9411/api/v1/spans #zipkin  aderss4.3 配置auth.yaml    请参考 2.34.4启动mesher./mesher4.5 启动client 此处和启动server一样，同样需要设置环境变量http_proxy或HTTP_PROXY，详细参考 2.6.5 访问在所有服务以及代理mesher全部启动完成之后，即可正常访问。此处的访问不同于我们以往通过ip+port访问，此处我们可以直接通过服务名(microservice.yaml中的name配置项)。如：server_A和server_B都是向外提供 /hello 接口，此时client 可以通过 http://server_A/hello 对server_A进行访问，server_A可以通过 http://server_B/hello 对server_B进行访问注意：此时的server_A既作为provider又作为consumer，为保证链路的不断，client端发往server_A请求中的header，同时需要将其放在server_A发往server_B的请求中，此部分需要在业务代码中完成5.1 调用成功之后，访问 http://localhost:9411/zipkin/ 并进入调用链详细界面可以看到一下界面上图所示为一个完整调用链

最近在选型service mesh框架，对比istio和cse mesher。istio支持分布式跟踪，只需在应用调用http请求时，在http header里面添加相关的项即可。参考https://istio.io/docs/tasks/telemetry/distributed-tracing/CSE Mesher是否有类似的功能？如何配置？比如A -> A mesher -> B mesher -> B -> B mesher -> C mesher -> C想跟踪从A触发到B、C的请求，必须在B中传递相关跟踪的上下文才能保持链路的完整。