最近有朋友提出了问题：“是不是拥有了服务发现就是微服务了？”，对于这个问题，很难回答，毕竟微服务的定义在每个人心里都是不一样的，就像“互联网思维”一样，我们说得清“互联网”，却总也说不清楚什么是“互联网思维”（在这个思想开放的互联网时代，你我都是哈姆雷特，但是也是交流沟通便利性的时代）。今天总结这篇文章呢，来说说我对微服务的理解，以及再来探讨下微服务的定义。

首先，微服务是什么？

其实回头看看我之前写的《微服务指南走北》系列的第一篇《微服务指南走北（一）：微服务是什么》中描述的：微服务是基于Restful风格的，基于资源及资源操作一组API的集合，可以实现模块儿或者说是特定的业务范围内的一个完全独立、细粒度、自包含的一个服务。每个微服务提供一组API，供其他微服务或者应用客户端所用。

其中，包含如下几个要点：
1. 基于资源
2. 模块儿化或者业务独立

微服务的“微”究竟是什么意思

几个误区：

1. 模块儿化：不得不说，微服务确实可以天然实现模块儿化，将不同的模块划分为不同的服务。但是这里存在一个误区，就是很多人想要借用微服务来实现模块化，从而去分解庞大的系统；不能说这样做有什么问题，但是从解决问题的角度来说，微服务的主旨并不是为了实现模块化，并且只要架构合理，单体应用也可以做好模块化。同理，架构模式不合理，必然导致微服务管理上的灾难（以后单独写文章来聊聊这个问题）。
2. 服务微小化：微服务并不是说要将服务拆分成多个微小的服务，举个例子，假设java单体应用本来有2个功能，一个是账户管理，一个是订单管理。运行起来的WebServer一共占用内存是50M，假设其中20M是WebServer自身占用的内存，那么分为两个微服务以后，就需要单独启动两个WebServer，那么就需要多占用20M的内存（当然这里拿WebServer来讲，并不是很合适，毕竟jvm中自身有优化），如果进一步结合docker来使用，那么在docker中，还需要增加额外的内存，关于这个问题，就不详解了，想了解的朋友可以参考如下文章Analyzing java memory usage in a Docker container。内存还仅仅是一方面，由于服务拆分而导

数据仓库的基础概念

面向主题

从下图可以看出，面向主题中的主题，可以看做我们常常设计维度的时候部分维度的抽象，如下图中，顾客活动和和顾客其实都是维度，但是是不同的特殊维度。

粒度

数据仓库中粒度化的数据是重用性的关键，因为它可以由众多的用户以不同方式使用。

举例：

就拿我们常用的日期维度来说，我们常常把日期维度分为“年、季度、月、周、日、小时”等，那么这里的“年、季度、月、周、日、小时”就是不同的六个粒度（相对时间上的），假设数据仓库中在时间上的粒度是日，那么就需要建立以日为最小分组统计的聚合表，在这个聚合表中，最小可以看到以日为单位的统计数据。
如果要查看周、月、季度、年的相关统计数据，就可以基于日的数据来进行进一步统计及计算。那么问题来了，如果我要看小时的数据怎么办，没有办法的，除非设计的最小粒度为小时。这就是数据的重用性。
当然，同一数据仓库中，对于同一纬度的不同level，也可以有相应粒度对应的数据，但是这样会造成数据的冗余；当然，也可以根据具体使用情景，决定是否需要这样的冗余（原书中说的是双重粒度，这里我更喜欢称为是多重粒度）。

数据的异构

报表是否必须在数据仓库中进行

这个答案是不一定的
1. 有些操作型报表需要的数据，在数据仓库中并不存在。
2. 即使操作型报表需要的数据，都会在数据仓库中存在，但是也许当时操作型数据库用到数据的同时，数据并未被归集到DS中（一般DS中的数据并不是实时的，而是定期通过ETL处理的），那么就会出现时数据错乱。

数据仓库中的错误数据如何处理

错误是难免的，一般错误出现的情况有如下几种：

1. ETL过程设计错误
2. 操作型数据库中的数据是先write后update的数据

解决办法

1. 进入数据仓库中，找到相应的数据条目，将基础数据修改，并需要彻底找到所影响的条目，全部重新计算，否则会造成数据失去一致性。
2. 加入修正条目，即先加入一条数据，抵消之前的错误数据，再插入正确的数据，然后将受到影响的条目全部重新计算，但是这样会造成一个问题，也许修正后，根本无法再进行重新计算。

设计数据仓库

元数据

元数据在数据仓库的上层，并且记录

近段时间离职，跟同事们讲解我之前所做的微服务相关产品，对于同事们提出的问题，做了如下整理出来，加上自己的理解，分享出来跟大家一起探讨下：

问题预览

1. 我为什么要换微服务？能给我带来什么好处？
2. 从交互上来看，单体应用在处理业务实体之间的关系，直接由框架搞定，如java的hibernate等，而使用微服务，还要去花时间去重新整理甚至重构业务结构.
3. 微服务测试起来比较麻烦：首先微服务根据不同的业务实体划分资源服务，那么也许有些业务的操作，会涉及多个微服务，那么测试微服务的话，就需要将所有的相关服务都启动完成，才可以进行测试。
4. 微服务一般对外是restful服务，为了保证安全性，开销也是比较大的：一方面服务内部可能每次访问都需要安全检查，会降低效率；另一方面内部访问开启https，在证书部署维护方面也会增加压力
5. 一般情况下，很多服务都存在类似session等数据存储在内存中，而这些session只在同一WebServer中存在，一般无法进行多实例共享（当然也有共享的方案，但是需要相对复杂的集群设计），该如何解决这些数据的问题呢？
6. 接着上个问题，微服务的使用场景中，基本都需要实现单个服务多个实例的场景，以实现高可用，那么问题来了，我对单个服务运行了10个实例，那么该如何知道服务该向哪个服务发起访问呢？
7. 接着上个问题，当我运行10个WebServer的时候，在主机上需要使用10个端口进行对应，而服务多了以后，对于端口的消耗和管理也是个比较大的麻烦
8. 接着上个问题，一般的应用，我们可以使用haproxy来做代理，那么就需要每增加或者修改一次实例，就需要修改haproxy的配置，管理上的消耗也会成为比较大的麻烦，并且还有可能出错
9. 对于众多的微服务实例，服务较多的至少可以达到数百个甚至数千个，监控和管理上，也将比较大的挑战
10. 上面提到的很多软件，都是比较零散的软件堆叠出来的服务，有没有比较好的成套的解决方案？

问题及自己的理解

1. 我为什么要换微服务？能给我带来什么好处？

1. 可以解决复杂性的问题，在功能不变的情况下，分解为多个相互协作的微服务，通过rest API定义边界，这样极大易于开发、理解和维护。

2. 微服务架构是的每

首先alpine内嵌的是BusyBox，使用alpine的crontab实际就是使用BusyBox的crond服务，那么下来就简单介绍下如何使用吧，网上教程还是比较多的：

配置文件存放位置：

配置文件是在如下目录中的

/var/spool/cron/crontabs/root

使用方式

1. 向crontab的配置文件中添加配置

vi /var/spool/cron/crontabs/root
# 或者
crontab -e
# 填入如下内容,最后一行为我添加的测试任务
# do daily/weekly/monthly maintenance
# min   hour    day     month   weekday command
*/15    *       *       *       *       run-parts /etc/periodic/15min
0       *       *       *       *       run-parts /etc/periodic/hourly
0       2       *       *       *       run-parts /etc/periodic/daily
0       3       *       *       6       run-parts /etc/periodic/weekly
0       5       1       *       *       run-parts /etc/periodic/monthly
*       *       *       *       *       echo "test" >> /app/test.log

1. 启动crond

crond

1. 查看状态

ps
PID   USER     TIME   COMMAND
·····
   82 root       0:00 crond
  292 root       0:00 ps

1. 查看/app/test.log是否有输入内容

cat test.log 
test
test
test
test
test

OK,至此对于c

1. 准备好一个非常简单点的web项目（maven项目）

2. 准备好maven环境，并配置pom文件，关于jetty内容如下：

<!-- jetty dependecies begin -->
  <dependency>
   <groupId>org.eclipse.jetty</groupId>
   <artifactId>jetty-server</artifactId>
   <version>9.1.4.v20140401</version>
  </dependency>
  <dependency>
   <groupId>org.eclipse.jetty</groupId>
   <artifactId>jetty-webapp</artifactId>
   <version>9.1.4.v20140401</version>
  </dependency>
  <dependency>
   <groupId>org.eclipse.jetty</groupId>
   <artifactId>jetty-continuation</artifactId>
   <version>9.1.4.v20140401</version>
  </dependency>
  <dependency>
   <groupId>org.eclipse.jetty</groupId>
   <artifactId>jetty-jsp</artifactId>
   <version>9.1.4.v20140401</version>
  </dependency>
  <!-- jetty dependecies end -->

3. 使用eclipse对maven项目进行build，获取build后的项目目录（或者将项目达成war包）

4. 创建运行配置jetty的Server类

运行war包的类

public class WebAppWarServer {
 public static void main(String[] args) throws Exception {
  Server server = new Server(8080);