首页 文章 精选 留言 我的

精选列表

搜索[组织重构],共10002篇文章
优秀的个人博客,低调大师

WCF服务重构实录(下)

前两篇写了在IIS7下部署SVC文件引导WCF服务,采用了net.tcp文件,但是实际的开发中,由于项目的架构已经确定,不宜做大的改动,且为了试项目组成员开发方便,我们之前的项目架构是这样的: 主体是WebHost,这是用来托管WCF服务的,放弃了ConsoleHost,那么现在的问题是能不能仅仅通过配置文件来托管服务,不必通过SVC文件的连接呢,MSDN上给出了一个很好的解决方案:http://msdn.microsoft.com/zh-cn/library/ee816902(en-us,VS.100).aspx 主要使用的是一个配置元素<serviceActivations>,MSDN给出的说明是: 一个配置元素,用于添加可定义虚拟服务激活设置(映射到 Windows Communication Foundation (WCF) 服务类型)的设置。使用此配置元素可以在不使用 .svc 文件的情况下激活承载在 WAS/IIS 中的服务。 主要语法是: view source print ? <SERVICEHOSTINGENVIRONMENT> <SERVICEACTIVATIONS> <ADDfactory="String"service="String"/> </SERVICEACTIVATIONS> </SERVICEHOSTINGENVIRONMENT> 那么有了这个好组件,我们就拿来改造现有的服务吧。 首先,之前的服务配置是 view source print ? <SERVICES> <SERVICEbehaviorconfiguration="MyBehavior"name="WCFLib.Add"> <ENDPOINTaddress=""binding="netTcpBinding"contract="WCFLib.IAdd"bindingconfiguration="netTcpBindConfig"></ENDPOINT> <ENDPOINTaddress="mex"binding="mexTcpBinding"contract="IMetadataExchange"></ENDPOINT> </SERVICE> </SERVICES> 我们为这个配置增加服务激活配置 view source print ? <SERVICEHOSTINGENVIRONMENT> <SERVICEACTIVATIONS> <ADDservice="WCFLib.Add"relativeaddress="NewAddService.svc"/> </SERVICEACTIVATIONS> </SERVICEHOSTINGENVIRONMENT> 来看一下现在完整的配置 view source print ? <SYSTEM.SERVICEMODEL> <BINDINGS> <NETTCPBINDING> <BINDINGname="netTcpBindConfig"> <SECURITYmode="None"> <TRANSPORTclientcredentialtype="Windows"protectionlevel="EncryptAndSign"/> <MESSAGEclientcredentialtype="Windows"/> </SECURITY> </BINDING> </NETTCPBINDING> </BINDINGS> <SERVICEHOSTINGENVIRONMENT> <SERVICEACTIVATIONS> <ADDservice="WCFLib.Add"relativeaddress="NewAddService.svc"/> </SERVICEACTIVATIONS> </SERVICEHOSTINGENVIRONMENT> <SERVICES> <SERVICEbehaviorconfiguration="MyBehavior"name="WCFLib.Add"> <ENDPOINTaddress=""binding="netTcpBinding"contract="WCFLib.IAdd"bindingconfiguration="netTcpBindConfig"></ENDPOINT> <ENDPOINTaddress="mex"binding="mexTcpBinding"contract="IMetadataExchange"></ENDPOINT> </SERVICE> </SERVICES> <BEHAVIORS> <SERVICEBEHAVIORS> <BEHAVIORname="MyBehavior"> <SERVICETHROTTLINGmaxconcurrentcalls="1000"maxconcurrentinstances="1000"maxconcurrentsessions="1000"/> <SERVICEMETADATAhttpgetenabled="true"/> <SERVICEDEBUGincludeexceptiondetailinfaults="true"/> <DATACONTRACTSERIALIZERmaxitemsinobjectgraph="6553600"/> </BEHAVIOR> </SERVICEBEHAVIORS> </BEHAVIORS> </SYSTEM.SERVICEMODEL> 删除SVC文件后的目录是这样的 那么怎么使用这个没有SVC文件的WCF服务呢,很简单,我们只要认为有这个服务就可以了,删除之前的Client中的引用,我们重新添加引用一下 再运行一下试试看 本文转自xshf12345 51CTO博客,原文链接:http://blog.51cto.com/wengyuli/583882,如需转载请自行联系原作者

优秀的个人博客,低调大师

Doris索引组织方式、查询与ROLLUP

1. Doris 前缀索引 doris不支持在任意列上创建索引,而是按照指定的列对数据进行排序存储,在这种数据结构上,以排序列作为条件查询会非常的高效。 在Aggregate,Uniq,Duplicate三种数据模型中,底层的数据存储,是按照各自建表语句中,AGGREGATE KEY,UNIQ KEY,DUPLICATE KEY中指定的列进行排序存储。 doris创建的索引是稀疏索引,将一行数据按照排序列的顺序进行存储,然后取一行数据中前面不多于36个字节的数据作为索引。因此在查询时。将查询条件按照排序列进行排序,会提高查询效率。同样,创建表的时候字段顺序也应该也应该按照排序列的次序进行排序。 -- AGGREGATE KEY(siteid, city, username) 排序列的顺序与创建表的字段顺序一致 CREATE TABLE visit ( siteid INT, city SMALLINT, username VARCHAR(32), pv BIGINT SUM DEFAULT '0' ) AGGREGATE KEY(siteid, city, username) DISTRIBUTED BY HASH(siteid) BUCKETS 10 PROPERTIES("replication_num" = "1"); -- 查询条件和排序列的顺序一致 select * from visit where siteid = and city = and username = 2. ROLLUP 在 Doris 中,我们将用户通过建表语句创建出来的表成为 Base 表(Base Table)。Base 表中保存着按用户建表语句指定的方式存储的基础数据。 在 Base 表之上,我们可以创建任意多个 ROLLUP 表。这些 ROLLUP 的数据是基于 Base 表产生的,并且在物理上是独立存储的。Rollup 本质上可以理解为原始表(Base Table)的一个物化索引。建立 Rollup 时可只选取 Base Table 中的部分列作为 Schema。Schema 中的字段顺序也可与 Base Table 不同。 也就是说,rollup表其实是保存了base表中的一部分字段的数据。例如 -- rollup_visit中只保存了siteid这一个维度列以及pv这个value列 alter table visit add rollup rollup_visit(siteid,pv); 这样当我们按照siteid去统计pv的聚合值的时候,可以通过查询 -- 查询的依旧是原始表 select siteid,sum(pv) from visit group by siteid; -- 查询计划 select siteid,sum(pv) from visit group by siteid; rollup也是有前缀索引的,sql语句按照前缀匹配对应的rollup,自动去对应的rollup中查询对应的数据。 因此,我们可以通过创建不同的rollup,来指定不同的排序列的顺序,以适应不同的查询方式。 ROLLUP 是附属于 Base 表的,可以看做是 Base 表的一种辅助数据结构。用户可以在 Base 表的基础上,创建或删除 ROLLUP,但是不能在查询中显式的指定查询某 ROLLUP。是否命中 ROLLUP 完全由 Doris 系统自动决定。 ROLLUP 的数据是独立物理存储的。因此,创建的 ROLLUP 越多,占用的磁盘空间也就越大。同时对导入速度也会有影响,但是不会降低查询效率; ROLLUP 的数据更新与 Base 表示完全同步的; 查询能否命中 ROLLUP 的一个必要条件(非充分条件)是,查询所涉及的所有列(包括 select list 和 where 中的查询条件列等)都存在于该 ROLLUP 的列中。否则,查询只能命中 Base 表。

优秀的个人博客,低调大师

Apache Storm 官方文档 —— 源码组织结构

Strom 的代码有三个层次: 第一,Storm 在一开始就是按照兼容多语言的目的来设计的。Nimbus 是一个 Thrift 服务,拓扑也被定义为 Thrift 架构。Thrift 的使用使得 Storm 可以用于任何一种语言。 第二,所有的 Storm 接口都设计为 Java 接口。所以,尽管 Storm 核心代码中有大量的 Clojure 实现,所有的访问都必须经过 Java API。这就意味着 Storm 的每个特性都可以通过 Java 来实现。 第三,Storm 的实现中大量使用了 Clojure。可以说,Storm 的代码结构大概是一半的 Java 代码加上一半的 Clojure 代码。但是由于 Clojure 更具有表现力,所以实际上 Storm 的核心逻辑大多是采用 Clojure 来实现的。 下面详细说明了每个层次的细节信息。 storm.thrift 要理解 Storm 的代码架构,首先需要了解storm.thrift文件。 Storm 使用这个fork版本的 Thrift(“storm” 分支)来生成代码。这个 “fork” 版本实际上就是 Thrift7,其中所有的 Java package 也都重命名成了org.apache.thrift7。在其他方面,它与 Thrift7 完全相同。这个 fork 主要是为了解决 Thrift 缺乏向后兼容的机制的问题,同时,也可以让用户在自己的 Storm 拓扑中使用其他版本的 Thrift。 拓扑中的每个 spout 或者 bolt 都有一个特定的标识,这个标识称为“组件 id”。组件 id 主要为了从拓扑中 spout 和 bolt 的输出流中选择一个或多个流作为某个 bolt 订阅的输入流。Storm 拓扑中就包含有一个组件 id 与每种类型的组件(spout 与 bolt)相关联的 map。 Spout 和 Bolt 有相同的 Thrift 定义。我们来看看Bolt 的 Thrift 定义。它包含一个ComponentObject结构和一个ComponentCommon结构。 ComponentObject定义了 bolt 的实现,这个实现可以是以下三种类型中的一种: 一个 Java 序列化对象(实现了IBolt接口的对象)。 一个用于表明其他语言的实现的ShellComponent对象。以这种方式指定一个 bolt 会让 Storm 实例化一个ShellBolt对象来处理基于 JVM 的 worker 进程与组件的非 JVM 实现之间的通信。 一个带有类名与构造器参数的 Java 对象结构,Storm 可以使用这个结构来实例化 bolt。如果你需要定义一个非 JVM 语言的拓扑这个类型会很有用。使用这种方式,你可以在不创建并且序列化一个 Java 对象的情况下使用基于 JVM 的 spout 与 bolt。 ComponentCommon定义了组件的其他方面特性,包括: 该组件的输出流以及每个流的 metadata(无论是一个直接流还是基于域定义的流); 该组件消费的输入流(使用流分组所定义的一个将组件 id 与流 id 相关联的 map 来指定); 该组件的并行度; 该组件的组件级配置。 注意,spout 的结构也有一个ComponentCommon域,所以理论上说 spout 也可以声明一个输入流。然而 Storm 的 Java API 并没有为 spout 提供消费其他的流的方法,并且如果你为 spout 声明了输入流,在提交拓扑的时候也会报错。这是因为 spout 的输入流声明不是为了用户的使用,而是为了 Storm 内部的使用。Storm 会为拓扑添加隐含的流与 bolt 来设置应答框架(acking framework)。这些隐含的流中就有两个流用于从 acker bolt 向拓扑中的每个 spout 发送消息。在发现 tuple 树完成或者失败之后,acker 就会通过这些隐含的流发送 “ack” 或者 “fail” 消息。将用户的拓扑转化为运行时拓扑的代码在这里。 Java 接口 Storm 的对外接口基本上为 Java 接口,主要的几个接口有: IRichBolt IRichSpout TopologyBuilder 大部分接口的策略为: 使用一个 Java 接口来定义接口; 实现一个具有适当的默认实现的 Base 类。 你可以从BaseRichSpout类中观察到这种策略的工作机制。 如上所述,Spout 和 Bolt 都已经根据拓扑的 Thrift 定义进行了序列化。 在这些接口中,IBolt、ISpout与IRichBolt、IRichSpout之间存在着一些细微的差别。其中最主要的区别是带有 “Rich” 的接口中增加了declareOutputFields方法。这种区别的原因主要在于每个输出流的输出域声明必须是 Thrift 结构的一部分(这样才能实现跨语言操作),而用户本身只需要将流声明为自己的类的一部分即可。TopologyBuilder在构造 Thrift 结构时所做的就是调用declareOutputFields方法来获取声明并将其转化为 Thrift 结构。这种转化过程可以在TopologyBuilder的源码中看到。 实现 通过 Java 接口来详细说明所有的功能可以确保 Storm 的每个特征都是有效的。更重要的是,关注 Java 接口可以让有 Java 使用经验的用户更易上手。 另一方面,Storm 的核心架构主要是通过 Clojure 实现的。尽管按照一般的计数规则来说代码库中 Java 与 Clojure 各占 50%,但是大部分逻辑实现还是基于 Clojure 的。不过也有两个例外,分别是 DRPC 和事务型拓扑的实现。这两个部分是完全使用 Java 实现的。这是为了说明在 Storm 中如何实现高级抽象。DRPC 和事务型拓扑的实现分别位于backtype.storm.coordination、backtype.storm.drpc和backtype.storm.transactional包中。 以下是主要的 Java 包和 Clojure 命名空间的总结。 Java packages backtype.storm.coordination: 实现了用于将批处理整合到 Storm 上层的功能,DRPC 和事务型拓扑都需要这个功能。CoordinatedBolt是其中最重要的类。 backtype.storm.drpc: DRPC 高级抽象的实现。 backtype.storm.generated: 为 Storm 生成的 Thrift 代码(使用了这个fork版本的 Thrift,其中仅仅将包名重命名为 org.apache.thrift7 来避免与其他 Thrift 版本的冲突)。 backtype.storm.grouping: 包含自定义流分组的接口。 backtype.storm.hooks: 用于在 Storm 中添加事件钩子的接口,这些事件包括任务发送 tuple、tuple 被 ack 等等。 backtype.storm.serialization: Storm 序列化/反序列化 tuple 的接口。这是在Kryo的基础上构建的。 backtype.storm.spout: Spout 与一些关联接口的定义(例如SpoutOutputCollector)。其中也包含有用于实现非 JVM 语言 spout 的协议的ShellSpout。 backtype.storm.task: Bolt 与关联接口的定义(例如OutputCollector)。其中也包含有用于实现非 JVM 语言 bolt 的协议的ShellBolt。最后,TopologyContext也是在这里定义的,该类可以用于在拓扑运行时为 spout 和 bolt 提供拓扑以及他们自身执行的相关信息。 backtype.storm.testing: 包含很多 bolt 测试类以及用于 Storm 单元测试的工具类。 backtype.storm.topology: 在 Thrift 结构上层的 Java 层,用于为 Storm 提供完全的 Java API(用户不必了解 Thrift)。TopologyBuilder和一些为不同的 spout 和 bolt 提供帮助的基础类都在这里。稍微高级一点的IBasicBolt接口也在这里,该接口是一种实现基本的 bolt 的简单方式。 backtype.storm.transactional: 事务型拓扑的实现。 backtype.storm.tuple: Storm tuple 数据模型的实现。 backtype.storm.utils: 整个代码库中通用的数据结构和各种工具类。 Clojure namespaces 译者注:Clojure 部分内容暂不提供翻译。 转载自并发编程网 - ifeve.com

优秀的个人博客,低调大师

GNOME 将彻底重构“窗口管理”

GNOME 46 或更高版本可能会对桌面的默认窗口管理 (Window Management) 进行彻底改造。 近日,GNOME 开发者 Tobias Bernard 通过一篇长文详细介绍了 GNOME 设计团队为重新设计桌面窗口管理所做的工作。终极目标是重新设计足以成为默认方案而非可选方案的方法。 Tobias Bernard是交互设计师,负责 GNOME 的设计,他研究了现在操作系统里放置窗口的常见方法(平铺、层叠/浮动),发现对新手用户而言,手动放置和缩放窗口的工作很繁琐。 他因此提出了自己的概念性设计,希望创造更理想的窗口管理方式。一些关键细节包括: 自动执行人们可能想要的操作,必要时允许调整 将工作空间 (workspaces) 作为工作流的完全集成部分来使用 从应用程序中获取更丰富的元数据,以便更好地进行整合 窗口采用三种布局排列方式相结合: 马赛克 (Mosaic),类似于平铺,并结合平铺和浮动的优势,且更自由 靠近边缘平铺,相当于局部的平铺 浮动,经典的层叠窗口模型 毫无疑问这是一项重大工作,将涉及大量窗口元数据,并需要在某些领域进行更多用户研究。目前该项目还处于非常早期的阶段,点此查看更多信息。

资源下载

更多资源
Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册