如下schema代码片段：

<?xml version="1.0"  encoding="UTF-8" ?>
<Schema name="报表">
    <cube name="cube_qc_pass_item" caption="报表1" encoding="UTF-8">
        <table name="fact_qc_pass_record_item_join">
        <Dimension name="models" foreignKey="model_id" caption="模板">
            <Hierarchy hasAll="true" allMemberName="model_name" primaryKey="id" primaryKeyTable="dim_qc_model">
                <Table name="dim_qc_model" />
                <Level name="model_name" column="name" caption="模板"/>
                <Level name="model_id" column="id" caption="model_id"/>
            </Hierarchy>
        </Dimension>
        <Measure name="times" column="id" aggregator="count" formatString="#,###0" datatype="Numeric" caption="总量"/>
    </cube>
</Schema>

我想要在使用mdx查询的时候，使用model_name显示，使用model_id作为查询条件限制某个model_id，该如何书写mdx语句？

已经有如下错误的mdx语句了

mdx查询语句1：

SELECT
NON EMPTY {Hierarchize({{[Measures].[times], [Measures].[notPass], [Measures].[pass]}})}

概述

软件开发过程中，往往会遇到版本管理问题，也常常会遇到服务多版本管理问题，也常常会遇到不同版本的服务之间，数据库字段不同、建表语句不同的问题，那么如何在不同版本间进行平滑升级，那么就需要有一系列的规范（暂不涉及回退方案）：

升级步骤

自动化管理，由程序在启动前操作：

1. 检查数据库中的当前版本，检查程序版本（version.properties中）
2. 检查与当前版本相关联的升级脚本（这一步骤依赖于与数据库版本相对应的文件命名规范）
3. 如果找到了文件，则执行文件内容并验证输出，如果出现错误则退出，抛出异常
4. 如果没有发现脚本，则直接退出，抛出异常
5. 重复步骤1

注意事项

1. 版本控制：数据库中存在db_schema_version表，用来管理当前所有应用实例的版本信息，每个项目中，都应包含一个version的描述文件（version.properties），有版本变动，即修改其版本信息，db_schema_version表结构见第6条
2. 版本号控制：<主版本号>.<子版本号>.<修订号>
   第一部分在系统的重要发布或重大阶段会进行改变，比如每几个月一次。下面两部分是由开发者控制的。子版本改变意味着数据库中加入了破坏性的改动（例如新的必需字段），这使得“旧的”应用程序与新的数据库架构不再兼容。修订号则是每次非破坏性的变动发生时（例如新的索引、新表、新的可选字段等等）进行递增的。每次上级版本号更新，下级版本号默认清零
3. 更新脚本：
   由开发者进行编写的数据库更新脚本，此脚本中包含多个更新数据库的语句，使用英文分号分隔（标准的数据库语句写法），不必特意使用事务脚本，java程序会将每一个更新脚本文件当做一个事务来处理。
   添加注释需要使用“ /注释/ ”方式来写
4. 更新脚本文件命名规范：
   为文件名称使用以下格式
   <前缀><数据库版本表中的当前版本号><目标版本号>_<有关升级的其它信息>.sql，
   例如：report_1.0.1_1.0.2_rename_column.sql
   目前，前缀我们默认使用产品名称来描述，用来和每个项目中配置文件中的product_name对应
   5、记录应用升级脚本的历史，db_version_h

本项目是将restful项目打包成可执行的war包，在docker中执行

环境介绍：

docker    1.10.3
jetty     8
jersey    1.19

项目代码：

https://git.coding.net/firewarm/docker-jetty-jersey1.x.git

关键配置：

1. pom.xml配置

<build>
<finalName>${project.artifactId}</finalName>
<plugins>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>${jetty.version}</version>
<configuration>
<systemProperties>
</systemProperties>
<webApp>
<contextPath>/</contextPath>
</webApp>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<id>attach-sources</id>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.

Docker的使用中，尤为重要的是服务发现和docker的宿主机集群及跨主机overlay网络的搭建，这里来介绍下常用来配合使用的swarm+consul集群的搭建（此处全基于docker容器）

集群介绍：

192.168.11.30 为consul服务的leader，swarm的集群server和client节点，并为primary

192.168.11.32 为consul服务的节点，swarm的集群server和client节点，并为备份节点

服务分布：

192.168.11.30：

consul、swarm、nginx

192.168.11.32：

consul、swarm、nexus、jenkins、registry

基础环境

修改docker基础配置

cluster-store 是consul的leader的地址

cluster-advertise 是swarm client的地址，即当前主机

11.30

vi /usr/lib/systemd/system/docker.service
ExecStart=/usr/bin/docker daemon --tls=false -H unix:///var/run/docker.sock  -H tcp://0.0.0.0:2375  --cluster-store=consul://192.168.11.30:8500 --cluster-advertise=192.168.11.30:2375 
systemctl daemon-reload
systemctl restart docker

11.32

vi /usr/lib/systemd/system/docker.service
ExecStart=/usr/bin/docker daemon --tls=false -H unix:///var/run/docker.sock  -H tcp://0.0.0.0:2375  --cluster-store=consul://192.168.11.30:8500 --cluster-

微服务“Microservices”已经成为软件架构最流行的热词之一。网络上看到很多关于微服务的文章，但是感觉很多离我们还很遥远，并且没有找到多少真正在企业场景中应用的实例。此处省略一万字~~~~于是想要将自己最近一段时间使用微服务以及通过看大师们的文章的所思所想梳理出来，分享出来，以供大家参考（热切欢迎大家拍砖，头破血流最好）。

一、什么是微服务

1. 记得刚看到微服务的时候，注意点在微字上，然后才是服务，初步理解为：将整块儿的服务拆分成多个类似工具类的微小web服务，供其他服务调用，每个服务应该是极其微小的，就像各个零件一样，各司其职，拼装成一个伟大的服务群

2. 由于自己是技术出身，对理论并不是很重视，于是基于初期的理解，就向着“微服务”（这里要打引号，不然会被拍板砖）迈进。先是实现了微服务的多种搭建方式，听说有springboot的、有jersey+jetty的、有Python的、有NodeJS的等等。进而了解到，微服务主要是以restful风格架构以提供服务（还有Thrift），rest的实现是HTTP的“请求-响应”，而rest是基于资源的API风格，进而可以理解微服务是多个能够表现对一个资源及对此资源执行的操作集成的服务。既然是对一个资源的使用及操作，那么每个微服务应该是独立的个体。

3. 基于以上理解，迫不及待的使用“微服务”来实现自己手上的业务需求，就拿简单的客户信息管理系统为例：主要有客户信息管理、用户管理、组织架构管理等（这里不多举例）。根据之前的理解，客户、用户、组织架构，应该是三种不同的资源，那么应该分为三个不同的微服务。可是某一层组织架构下，会有多个用户，而某个用户又会拥有属于自己的多个客户，如此并没有办法将三个服务彻底分离（还是有关联关系），这不符合之前的理解。然而业务关系上，三者的联系必不可少，存在即合理，那么也理应是三个微服务互相协作而又相互独立的关系。如同团队成员之间的协作关系，相互独立而又相互依赖。

小结：微服务是基于Restful风格的，基于资源及资源操作一组API的集合，可以实现模块儿或者说是特定的业务范围内的一个完全独立、细粒度、自包含的一个服务。每个微服务提供一组API