最近在做微服务相关产品，其中需要有API网关相关产品，虽然早有研究过API网关产品TYK，但是感觉其太重，想起之前研究开源BI产品saiku的时候，记得其有NodeJS的代理代码，于是看了下，颇有启发，略微修改了一些，拿出来跟大家分享下，虽然简单，不可用于生产，但是对于学习还是不错的

package.json

{
  "name": "SmartHttpProxy",
  "description": "An simplest Http Proxy",
  "version": "0.0.1",
  "author": "liuyg@liuyingguang.cn",
  "license": {
    "type": "Apache License Version 2"
  },
  "main": "server.js",
  "scripts": {
    "start": "node server.js 8088 127.0.0.1 80 / "
  },
  "dependencies": {
    "express": "~4.13.4"
  }
}

server.js

/*
 *
 *   Licensed under the Apache License, Version 2.0 (the "License");
 *   you may not use this file except in compliance with the License.
 *   You may obtain a copy of the License at
 *
 *       http://www.apache.org/licenses/LICENSE-2.0
 *
 *   Unless required by applicable law or agreed to in writing, software
 *   distributed under the License is distributed on an "AS IS" BASIS,
 *   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either e

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

首先，微服务是什么？

其实回头看看我之前写的《微服务指南走北》系列的第一篇《微服务指南走北（一）：微服务是什么》中描述的：微服务是基于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。内存还仅仅是一方面，由于服务拆分而导

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

问题预览

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. 微服务架构是的每

本项目是将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.

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

一、什么是微服务

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

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

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

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