互联网架构中的9种隔离术以及容器化的实现
互联网架构中的9种隔离术以及容器化的实现
9种隔离术
在硬件方案设计的时候，我们常提到过一个概念“故障域”。故障域指的是当一个区域出现故障以后，它的受影响范围。例如在设计双活数据中心的时候，我们要设置故障域，那个故障域是A站点，哪个是B站点。A站点出现断电，受影响的最大范围只限于本站点，那么A站点就是一个故障域。当然，硬件层面的故障域还可以分得更细：比如一个数据中心内部，不同楼层是不同的故障域；同一个楼层，不同的机架也是不同的故障域。在故障域这个问题上，关键是看故障的类型如何定义。
而隔离技术就是限制故障域的。当然，应用级别的隔离术比硬件的隔离更为细致。其中包括：
1.线程隔离
线程隔离主要指的是线程池隔离。根据前端的请求不同，把需求转发到不同的线程池中。
如下如，tomcat在收到http请求以后，按照不同的请求类型，将请求转发到核心业务队列或者非核心业务队列。
2.进程隔离
我们知道，交易和论坛都是电商系统很重要的两部分。在以前，一个电商系统如果不被拆分的情况下，交易请求和论坛请求都会访问同一个应用（一个或多个实例）。当系统拆分以后，论坛系统和交易系统是不同的应用，这样不仅醉倒了进程隔离，也提高乐整体性能。
3.集群隔离
集群隔离指的是，当电商系统某一个功能模块，单实例应用无法满足需求的时候，需要部署多个服务形成服务集群。
例如在下图中，目录服务和评论服务组成了不同的服务集群。如果访问的请求量高，那么目录服务集群中实例的数量可以增加；同样，评论的人多的时候，评论服务集群的应用实例也可以增加。
4.机房隔离
机房隔离是为了满足应用高可用的要求。每个机房的前端，可以通过DNS/负载均衡进行分流。或者在客户端的请求中，指明机房的分组标签。机房隔离是比较传统的隔离技术，这里我们不进行详细讨论。
5.读写隔离
读写隔离又称读写分离。读写分为通常指的是数据库，如传统的RDBMS：Oracle DB、MySQL/Maria DB，以及缓存如：redis（key-value）、memcached（key-value）等。读写分离除了可以提高性能，还有一个好处是，当主集群出现问题的时候，如果没法写入数据，但用户客户从备集群读取数据。
关于MySQL集群的容器化实践，请参照笔者之前的文章：
6.动静隔离
大家都有网购的经历。网购的页面，有的是静态页面，有的是动态页面。例如：服装的图片是静态的，而附件界面是动态的。为了保证性能，电商通常将动态内容与静态资源分离，而一般静态资源放在CDN上。
7.爬虫隔离
网络爬虫，大家可以理解为在网络上爬行的一直蜘蛛，互联网就比作一张大网，而爬虫便是在这张网上爬来爬去的蜘蛛咯，如果它遇到资源，那么它就会抓取下来。比如它在抓取一个网页，在这个网中他发现了一条道路，其实就是指向网页的超链接，那么它就可以爬到另一张网上来获取数据。这样，整个连在一起的大网对这之蜘蛛来说触手可及.
在用户浏览网页的过程中，我们可能会看到许多好看的图片，我们会看到几张的图片以及百度搜索框，这个过程其实就是用户输入网址之后，经过 DNS 服务器，找到服务器主机，向服务器发出一个请求，服务器经过解析之后，发送给用户的浏览器 HTML、JS、CSS 等文件，浏览器解析出来，用户便可以看到形形色色的图片了.
根据统计，很多网站的怕刘流程和正常流量访问比率可高达5:1，这种情况下，可以将爬虫路由到单独的集群。
8.热点隔离
抢购、秒杀、开门红等业务，都属于热点。对于这种系统，应该造成独立的系统进行隔离，底层使用配置较高的硬件服务器、更好的网络带宽，并且加入多级缓存。
详见笔者此前文章：
9.资源隔离
资源隔离是比较好理解发的。如CPU、内存、IO的隔离。这同样属于传统硬件隔离范畴。基本原则是，按照业务特点，业务区域。如CPU密集型的应用，底层服务器多配置主频高的处理器，大内存访问的应用，配置内存高的服务器。另外，对于到多数I/O访问量高的应用，通常使用SSD磁盘。这点本文不再详细赘述。
隔离术的容器化实验
参照红帽的一个容器化电商的代码（https://github.com/jbossdemocentral/coolstore-microservice），其架构如下。
从最外端的Web UI开始，这是一个用node.js写的微服务。用于对外提供访问，接受用户的请求。接下来是CoolStore的GW,其实就是这套微服务的API Gateway，Spring boot书写。指向到CoolStore的GW的Hystrix和Turbine负责微服务的熔断。
接下来的六个微服务，从左右往右：Rating Service、Review Service、Inventory Service、Catelog Service、Cart Service、Pricing Service。则是我们网购的时候，调用后端的微服务。其实也就是网购具体的应用。
- Catelog Service，也就是目录服务 - JBoss 的Java应用程序，为零售产品提供产品和价格.
- Cart Service,也就是购物车服务 - 在每个客户管理购物车的JDK上运行的Spring Boot应用程序
- Inventory Service，也就是库存服务 - 在JBoss EAP 7和PostgreSQL上运行的Java EE应用程序，为零售产品提供库存和可用性数据
- Pricing Service，也就是定价服务 - JBoss BRMS产品定价业务规则应用
- Review Service，也就是审查服务 - 在JDK上运行的WildFly Swarm服务，用于撰写和显示产品评论
- Rating Service，也就是评级服务 - 在JDK上运行的Vert.x服务用于评级产品
- Coolstore API网关 - 在JDK上运行的Spring Boot + Camel应用程序作为后端服务的API网关。
- Web UI - 在Node.js容器中运行的基于AngularJS和PatternFly的前端。也就是客户访问电商的界面展示。
我们可以看到，在上图中，Rating Service、Review Service、Inventory Service、Catelog Service这四个微服务，都有自己的数据库。这其实正是符合微服务的share as little as possible原则。即说微服务应该尽量设计成边界清晰不重叠，数据独享不共享。实现所谓的“高内聚、低耦合”。这样有助于实现独立可部署（independently deployable）。
在这个案例中，前文提到的：线程隔离、进程隔离、集群隔离、读写隔离、爬虫隔离、机房隔离、热点隔离、资源隔离都已经可以实现。而动静隔离只要前面增加CDN即可。
线程隔离：客户端发起不同的请求，CoolStore的网关根据请求的类型，查分发送到不同的微服务。如有的用户是浏览购物记录，有的是查价格，有的看评论等等。
进程隔离：各个后台微服务之间，就是进程隔离。
集群隔离：每个后台的微服务都是一个service，每个service都可以有多个Pod，也就是多个应用实例，组成应用集群。
读写隔离：将微服务后端的数据库按照读写分离的方式部署到容器中即可。
爬虫隔离：可以将其作为微服务进行部署。
机房隔离：PaaS架构搭建的时候，可以跨机房。对不同机房的物理服务器打label即可。这样部署容器的时候，就可以将一个应用不同的容器实例跨机房。
热点隔离：电商里，web-ui、评论等容易出现热点的微服务，可以通过打标签的方式，部署到配置高的服务器上。
资源隔离：与机房隔离类似，通过对服务器打标签，在部署微服务的时候，可以将不同的服务部署到不同的物理服务器上，实现资源隔离。
所以说，微服务很适合互联网架构，而容器很适合微服务。在容器化的微服务中，API网关是个很重要的角色。在微服务中，API网关很多时候需要引入hystrix这个熔断器。
针对本案例，我们可以看一下API网关的源码：
API网关的源码中，有对后端多个微服务的调用方式，我们查看API网关对评论服务的调用：
我们看最后一个，对评论的调用方式，在
主代码中，对hystrix进行了参数值覆盖：
而ReviewGateway.java上面这段代码对hystrix的调用，在其他代码中已经注明：
ReviewGateway.java代码中也定义了对评论这个微服务的restful API调用：
参考文档
https://github.com/jbossdemocentral/coolstore-microservice/blob/1.1.x/coolstore-gw/src/main/java/com/redhat/coolstore/api_gateway/ReviewGateway.java
http://wiki.jikexueyuan.com/project/python-crawler-guide/understand-the-basic.html