信息架构

客户端自动化特点 客户端的自动化，通常做过的人都不是很愿意深入讨论。因为除了功能和逻辑之外，不得不面对各种界面变化，各种和环境交互，各种兼容问题以及想不到灰色地带，就算这样，也找不到太多有效的bug。然而即便如此，客户端的自动化必须去做，尤其是GUI的。它的自动化特点是： 复杂 成本高 不容易发现问题 技术要求高 架构很难通用 下面，从一些基本的东西开始一点点的讨论客户端GUI测试的一些问题和处理办法，以及自动化架构设计的一些思路。事实上就像上面说的，GUI的测试并不是为了发现bug，而是回归的一种方式，作为保证而已——它过了不能说明质量多么好，但是不过，质量肯定不达标。即使在微软内部，客户端的GUI一样不是个受欢迎的家伙，通常用来做BVT的测试（或一些重要性回归，冒烟等）。 客户端自动化简述 这里并不花过多的笔墨介绍什么是客户端，或者如何分类的种种——这些东西教材和网上的东西一坨一坨很多很多，这里可能“漫谈”的，是实际工作中，客户端和GUI自动化中可能遇到的一些底层技术，基本上原理，架构设计方法以及一些项目存在困惑，这些方面的一些处理的方法。 最早的自动化 我个人认为所谓的计算机行业的自动化，是一直跟着这个行业的发展在走，比如下面的这些： 老式计算机——CPU计算： 最早自动解决手工分配穿孔的卡片问题 内存分配任务调度：操作系统的核心就是内存和任务的自动管理 系统配置Loader

转自： https://www.cnblogs.com/arnoldlu/p/7406441.html 1.前言 了解Linux中断子系统，同时也需要了解ARM体系结构中断处理流程；在熟悉整个软硬件架构和流程基础上，才能对流程进行细化，然后找出问题的瓶颈。《 2. 梳理中断处理子系统 》 但是所有的优化都离不开一个量化的过程，有个可靠、高效、可读性强的度量必不可少。《 3. 一种测量中断性能手段 》 最后基于此，进行中断性能的优化。《 4.中断性能优化 》 2. 梳理中断处理子系统 中断系统涉及到软硬件两部分，具体到ARM系统和Linux涉及到很多相关点。 硬件以Cortex-A53为基础，整个GIC架构包括两部分：CPU内部的GIC CPU Interface( Cortex-A53 Chapter 9 )和CPU外部的GIC external distributor component。 《ARM Cortex-A53 MPCore Processor Technical Reference Manual》简单介绍了A53核内部的GIC CPU Interface。 《ARM Generic Interrupt Controller Architecture Specification v3/v4》详细介绍了整个GIC架构的方方面面，具体实现比如GIC-600在《GIC-600

https://blog.csdn.net/szwandcj/article/details/51025669 Cat功能强大且多，光日志的报表和图表分析就有十几种，但文档却很少，寥寥无几找到一些粒度却还很粗而且都是偏功能性的介绍。此外cat的配置也特别丰富，但几乎所有的cat文档里却鲜少提及。这些都导致很多方面都是缺失的，尤其是对于使用者来说，缺失了这些可能就意味着后面会步入大坑。 大纲 大众点评Cat–整体架构 大众点评Cat–server架构分析 整体架构 Cat的定位是实时监控平台，但是与其说是监控平台，更像是个数据仓库，在数据仓库的基础上提供丰富的报表分析功能。 Cat分c端和s端，c使用cat接口向s上报统一格式的日志信息。Cat的c是产生日志的地方（一般来说就是被监控的应用，上图中的应用节点），相应的s则是接受日志、消费日志的地方（上图中的server节点），日志消费后生成会日志报表。 S分为job machine, alert machine和sender machine，前者表示可以运行定时任务的节点，后者则代表可以进行告警任务的节点。定时任务将报表数据转换成图表数据；告警则基于一定规则对报表数据做筛选剔出相应的告警数据，还有种特殊的告警用于对第三方应用做ping（2次ping不通或者超时则告警），告警节点如果不同时是发送节点则只保存告警信息

MySQL复制 （1）扩展方式： Scale Up ，Scale Out （2）MySQL的扩展 读写分离 复制：每个节点都有相同的数据集 向外扩展 二进制日志 单向 （3）复制的功用： 数据分布 负载均衡读 备份 高可用和故障切换 MySQL升级测试 一主多从　　 主从复制原理 （1）从库生成两个线程，一个I/O线程，一个SQL线程； （2）i/o线程去请求主库 的binlog，并将得到的binlog日志写到relay log（中继日志） 文件中；主库会生成一个 log dump 线程，用来给从库 i/o线程传binlog； （3）SQL 线程，会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致； 主从复制线程： 主节点： dump Thread：为每个Slave的I/O Thread启动一个dump线程，用于向其发送binary log events 从节点： I/O Thread：向Master请求二进制日志事件，并保存于中继日志中 SQL Thread：从中继日志中读取日志事件，在本地完成重放 跟复制功能相关的文件： master.info：用于保存slave连接至master时的相关信息，例如账号、密码、服务器地址等 relay-log.info：保存在当前slave节点上已经复制的当前二进制日志和本地replay

关于区块链应用方向与前景的一些思考 https://www.cnblogs.com/zhang-qc/p/9664742.html # 转载请注明 监管与创新，技术与应用 （ 下面写的主要偏向金融行业区块链应用 ） 金融行业中所用的系统基本都是 中心化的 ，多年来这么运行都没什么问题，效率高，也比较可靠，数据的存储和使用权都在自己手中。 中心化主要带来的问题有两个： （1） 中心化的架构下跨系统跨平台的流程很难去优化 。因为跨系统其实就是跨信任域，首先不同系统的接口、格式和规范这些都不同，对接起来麻烦；其次执行信用认证、合约规定，还有监管需要的资源多，成本大； （2） 安全风险 ，针对于可靠性。中心化架构存在单点失效的可能，另外集中存储可能带来数据安全问题（丢失、泄露）。 国内现在区块链的主流（针对于大众企业来说）还是在多中心有中介的联盟链。应用主要包括两种模式： （1） 利用区块链技术建立多维度直接交互架构 ，就是将业务场景中的系统分布式化。现在有很多支持构建的底层平台，例如微众fisco，平安壹帐通，这些都是联盟链平台，大多是基于以太坊或fabric改的。那么可以在其上构建联通各方的应用。比如有 小微企业商贷：区块链中分阶段记录小微企业全流程的信贷信息，用户可以安全选择共享贷款信息。解决信息的不对称问题，提高小微企业贷款效率。（贷款不光只有用户，还有企业，贷款的种类也很多

目录 前言 一、微服务介绍 1.什么是微服务 2. 微服务由来 3. 为什么需要微服务？ 3.1 早期的单体架构带来的问题 3.2 微服务与单体架构区别 3.3 微服务与SOA区别 4. 微服务本质 5. 什么样的项目适合微服务 6. 微服务折分与设计 6.1 微服务设计原则 7. 微服务优势与缺点 7.1 特性 7.2 特点 7.3 缺点 8. 微服务开发框架 9. Sprint cloud 和 Sprint boot区别 二、微服务实践先知 1. 客户端如何访问这些服务？（API Gateway） 2. 服务之间如何通信？（服务调用） 3. 这么多服务怎么查找？（服务发现） 4. 服务挂了怎么办？ 5. 微服务需要考虑的问题 三、微服务重要部件 1. 微服务基本能力 2. 服务注册中心 2.1 zookeeper服务注册和发现 3. 负载均衡 3.1 负载均衡的常见策略 4. 容错 4.1 容错策略 5. 熔断 6. 限流和降级 7. SLA 8. API网关 9. 多级缓存 10. 超时和重试 11. 线程池隔离 12. 降级和限流 13. 网关监控和统计 前言 到底什么是微服务？为什么要用微服务？微服务主要来做一些什么？微服务有哪些优势？什么样的服务属于微服务？本文所有资料来源网络，我只是整理一下，总结一下。仅供参考。 一、微服务介绍 1.什么是微服务 在介绍微服务时

【From】 https://blog.csdn.net/u013332124/article/details/88350345 Spark History Server 是spark内置的一个http服务，通过sbin/sbin/start-history-server.sh启动。History Server启动后，会监听一个端口，同时启动两个定时任务线程，分别用来解析eventLog日志文件和清理过期的eventLog日志文件。 Spark History Server启动后，我们可以直接在浏览器输入 http://ip:port 访问。一般默认端口是18080 一、eventLog日志文件以及相关参数 eventLog日志文件介绍 eventLog需要将配置spark.eventLog.enabled设置为true来开启，默认是关闭的。 开启这个配置后，当我们提交spark job到集群中运行时，之后spark job在运行过程中会不断的一些运行信息写到相关的日志文件中。具体的eventLog存放目录由配置spark.eventLog.dir决定的。 Spark job在运行中，会调用EventLoggingListener#logEvent()来输出eventLog内容。spark代码中定义了各种类型的事件，一旦某个事件触发，就会构造一个类型的Event

在 ASP.NET Core 项目中使用 MediatR 实现中介者模式 一、前言 # 　　 最近有在看 DDD 的相关资料以及微软的 eShopOnContainers 这个项目中基于 DDD 的架构设计，在 Ordering 这个示例服务中，可以看到各层之间的代码调用与我们之前传统的调用方式似乎差异很大，整个项目各个层之间的代码全部是通过注入 IMediator 进行调用的，F12 查看源码后可以看到该接口是属于 MediatR 这个组件的。既然要照葫芦画瓢，那我们就先来了解下如何在 ASP.NET Core 项目中使用 MediatR 。 　　代码仓储： https://github.com/Lanesra712/grapefruit-common/tree/master/sample/aspnetcore/aspnetcore-mediatr-tutorial 二、Step by Step # 　　 MediatR 从 github 的项目主页上可以看到作者对于这个项目的描述是基于中介者模式的 .NET 实现，是一种基于进程内的数据传递。也就是说这个组件主要实现的是在一个应用中实现数据传递，如果想要实现多个应用间的数据传递就不太适合了。从作者的 github 个人主页上可以看到，他还是 AutoMapper 这个 OOM 组件的作者，PS，如果你想要了解如何在 ASP

SOA( Service-Oriented Architecture ) 面向服务的体系结构 SOA( Service-Oriented Architecture ) 是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以使用一种统一和通用的方式进行交互。 目录 1. 1 定义介绍 2. 2 体系结构 3. ▪ 松耦合的系统 4. ▪ 体系结构作用 5. 3 特性状况 1. 4 新兴变革 2. 5 为何选择 SOA 3. ▪ 简介介绍 4. ▪ 服务架构 5. ▪ 基础结构 6. ▪ 服务品质 1. ▪ 安全质量 2. ▪ 可靠信度 3. ▪ 策略计划 4. ▪ 控制能力 5. ▪ 管理能力 6. ▪ Web 服务 1. ▪ SOA 优势 2. ▪ 发展效益 3. ▪ 主要优势 4. ▪ 推动因素 5. 6 优点 定义介绍 编辑 面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是 SOA 的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。 SOA 是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

由于 ROS 系统的组织架构比较复杂，简单从一个方面来说明很难说清楚。按照 ROS 官方的说法，我们可以从 3 个方面来理解 ROS 系统整体架构，这 3 个方面分别是文件系统级、计算图级、开源社区级。 1. 从文件系统级理解 ROS 架构 如果你是刚刚接手 ROS 方面的开发或项目，你肯定会觉得 ROS 中的各种概念非常奇怪，但是当你对 ROS 的使用熟练之后，你就觉得这些概念很好理解了。与其他操作系统相似，一个 ROS 程序的不同组件要被放在不同的文件夹下，这些文件夹是根据不同的功能来对文件进行组织的，如图 3 。 （图 3 ）文件系统级理解 ROS 架构 （ 1 ）工作空间 工作空间是一个包含功能包、可编辑源文件和编译包的文件夹，当你想同时编译不同的功能包时非常有用，并且可以保存本地开发包。当然，用户可以根据自己的需要创建多个工作空间，在每个工作空间中开发不同用途的功能包。不过作为学习，我们先以一个工作空间为例。如图 3 ，我们创建了一个名为 catkin_ws 的工作空间，该工作空间下会有 3 个文件夹： src 、 build 、 devel 。 src 源文件空间 ：这个文件夹放置各个功能包和一个用于这些功能包的 CMake 配置文件 CMakeLists.txt 。这里做一下说明，由于 ROS 中的源码采用 catkin 工具进行编译，而 catkin 工具又是基于