微服务指南走北（四）：你不肯意作微服务架构的十个理由

近段时间离职，跟同事们讲解我以前所作的微服务相关产品，对于同事们提出的问题，作了以下整理出来，加上本身的理解，分享出来跟你们一块儿探讨下：

问题预览

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. 微服务架构是的每一个服务能够由专门的开发团队或者我的开发者进行开发，开发者能够自由选择技术，没必要受制于规定的技术和框架，只要API服务协议好交互方式便可（如restful）。这样即便从新技术过期的微服务模块儿或者重写之前的代码，也不是很困难。

3. 微服务架构模式使得每一个微服务独立部署，且每一个服务独立扩展，开发者再也不须要协调其它服务部署对本服务的影响。微服务架构模式使得持续化部署成为可能。

2. 从交互上来看，单体应用在处理业务实体之间的关系，直接由框架搞定，如java的hibernate等，而使用微服务，还要去花时间去从新整理甚至重构业务结构.

首先，在使用框架的同时，也已经受制于框架，甚至是开发语言的选择，单体应用下，看似方便，但是业务实体之间的关系太过于固化，当有一个业务实体须要改变，则整个应用至关于发布了一个新的版本。这种状况对于不care更新中止程序的客户来讲是无所谓，但是对于服务更新中止程序敏感性比较强甚至不容许中止程序的公司来讲，无疑是个灾难。因此使用微服务不是必须的，而是在适当的实际，架构适应应用场景的一种改变。

3. 微服务测试起来比较麻烦：首先微服务根据不一样的业务实体划分资源服务，那么也许有些业务的操做，会涉及多个微服务，那么测试微服务的话，就须要将全部的相关服务都启动完成，才能够进行测试。

微服务测试起来麻烦是没有任何疑问的，不过微服务大多采用restful服务，这为微服务的测试提供了相对的便利性（测试restful接口的工具仍是挺多的）。对于微服务带来的便利性，增长这点压力仍是能够容忍的。

4. 微服务通常对外是restful服务，为了保证安全性，开销也是比较大的：一方面服务内部可能每次访问都须要安全检查，会下降效率；另外一方面内部访问开启https，在证书部署维护方面也会增长压力

首先，通常微服务外部都是须要有API GateWay的，由API GateWay来保证外部访问的安全性，而内部访问，能够省去https和安全检查，仅保留必要的用户信息便可。

5. 通常状况下，不少服务都存在相似session等数据存储在内存中，而这些session只在同一WebServer中存在，通常没法进行多实例共享（固然也有共享的方案，可是须要相对复杂的集群设计），该如何解决这些数据的问题呢？

通常状况下，对于绝大部分有状态服务，在设计之初，就会考虑有状态服务的状态转移等工做，假设咱们有服务存在session，那么这些session信息，能够转嫁存储在一套redis集群中，这样子就能够多个实例都访问redis，至关于状态由redis进行处理了。

6. 接着上个问题，微服务的使用场景中，基本都须要实现单个服务多个实例的场景，以实现高可用，那么问题来了，我对单个服务运行了10个实例，那么该如何知道服务该向哪一个服务发起访问呢？

通常状况下，咱们可使用haproxy之类的服务，将当期服务的全部实例进行代理，能够先对单个服务单点访问，其余服务作备份，又可使用haproxy的负载均衡，使请求平均分发到各个服务中

7. 接着上个问题，当我运行10个WebServer的时候，在主机上须要使用10个端口进行对应，而服务多了之后，对于端口的消耗和管理也是个比较大的麻烦

可使用docker来解决，在docker的使用中，一个服务对应一个镜像，而基于一个镜像能够启动多个容器，而每一个容器均可以使用统一的内部端口，不一样的容器名称，咱们使用的haproxy也在docker中运行，经过docker内部网络访问各个服务，这样就解决了端口问题。

8. 接着上个问题，通常的应用，咱们可使用haproxy来作代理，那么就须要每增长或者修改一次实例，就须要修改haproxy的配置，管理上的消耗也会成为比较大的麻烦，而且还有可能出错

对于这个问题，也有解决方案：首先咱们能够去尝试使用以下一套解决方案“docker-swarm-consul-haproxy”，Swarm是一个用于建立Docker主机（运行Docker守护进程的服务器）集群的工具,consul用来服务发现及配置中心，haproxy则用来进行代理服务

9. 对于众多的微服务实例，服务较多的至少能够达到数百个甚至数千个，监控和管理上，也将比较大的挑战

不管是作以往的单体应用、SOA仍是微服务，服务监控和管理都是必不可少的，对于监控，目前有比较好的容器监控开源程序，如：Prometheus、 cAdvisor等；管理方案可使用简单的shipyard，复杂的可使用kubernetes的

10. 上面提到的不少软件，都是比较零散的软件堆叠出来的服务，有没有比较好的成套的解决方案？

总体的解决方案是有的，就是我的感受略重（我我的搭建的一些服务，没有用kubernetes，而是使用了很是简单compose+swarm）。这个方案就是使用kubernetes（基于Docker），下面能够简单描述下我这边是怎么使用kubernetes来实现微服务的：

1. 首选个人微服务程序都是无状态的或者通过状态转移过的

2. 对于服务发现，以往咱们用consul，这里我没有去作服务发现和服务注册，而是使用kubernetes的ReplicationController来保证个人微服务实例数量（系统会自动维护）

3. 对外的代理之前用haproxy，而如今使用kubernetes的service来替代，kubernetes自动处理各个微服务实例的负载及请求的分发，咱们只须要保证业务稳定便可。

---

by 刘迎光@萤火虫工做室
OpenBI交流群：495266201
MicroService 微服务交流群：217722918
mail: liuyg#liuyingguang.cn
博主首页（==防止爬虫==）：http://blog.liuyingguang.cn
OpenBI问答社区：http://www.openbi.tk