从零开始学习微服务架构(二)

　　做为一名IT从业者，懈怠是一件奢侈的事情，由于在IT圈，原地踏步就等于退步。

　　上一篇中，咱们已经笼统介绍了一下微服务，以及我在项目中是如何从传统单体模式向微服务演变的。本章咱们深刻探讨一下微服务的核心内容。

---

 

• 乱花渐欲迷人眼

　　　　当我刚刚开始接触微服务的时候，我听到了许多名次：“微服务”、“SOA”、“spring boot”、“spring cloud”、“docker”。面对这么多名词，一脑壳蒙圈～如今咱们来仔细理一理。

　　　　微服务：维基百科中是这么定义的：微服务 (Microservices) 是一种软件架构风格，它是以专一于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，本身拥有本身的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其余服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力，服务能够用不一样的编程语言与数据库等元件实做。

　　　　SOA：维基百科中是这么定义的：面向服务的体系结构（英语：service-oriented architecture）并不特指一种技术，而是一种分布式运算的软件设计方法。软件的部分组件(调用者)，能够经过网络上的通用协议调用另外一个应用软件组件运行、运做，让调用者得到服务。SOA原则上采用开放标准、与软件资源进行交互并采用表示的标准方式。所以应能跨越厂商、产品与技术。一项服务应视为一个独立的功能单元，能够远程访问并独立运行与更新，例如在在线线查询信用卡帐单。

　　　　spring boot：Spring Boot是由Pivotal团队提供的全新框架设计方式，其设计目的是用来简化新Spring应用的初始搭建以及开发过程。它使用“习惯优于配置”的理念让你的项目快速运行起来。所以Spring Boot并不能说是一个框架，而是一个集合或者工具。

　　　　spring cloud：百度百科中是这么定义的：Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，均可以用Spring Boot的开发风格作到一键启动和部署。Spring Cloud并无重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，经过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

　　　　docker：维基百科中是这么定义的：Docker是一个开放源代码软件项目，让应用程序布署在软件容器下的工做能够自动化进行，借此在Linux操做系统上，提供一个额外的软件抽象层，以及操做系统层虚拟化的自动管理机制^[1]。Docker利用Linux核心中的资源分脱机制，例如cgroups，以及Linux核心名字空间（name space），来建立独立的软件容器（containers）。这能够在单一Linux实体下运做，避免引导一个虚拟机形成的额外负担。

---

 

　　从以上的各名词解释上来看，咱们能够获得以下几个结论：

　　　　　1.微服务并非一个全新的框架，是一种软件架构设计风格。

　　　　　2.微服务也属于SOA，只是与传统的SOA存在着一些差异。微服务能够看做是SOA概念的升华，微服务中对于业务拆分更加细粒度，微服务更倾向于去中心化，去ESB总线。

  3.Spring Boot和Spring Cloud组合，是开发微服务的一个黄金组合套装。单并非说这两个东西才是微服务，只是咱们更习惯用这两个套件来进行开发，咱们也同样可使用其余工具来开发微服务。

  4.Docker是一种容器，基于LXC实现的。Docker的抽象性和隔离性很是适合部署微服务。但也并非说只有Docker才是微服务或者只有Docker才能部署微服务。咱们使用VM，甚至物理机同样能够部署微服务，只是从量级以及编排部署等方面考虑，使用Docker容器更容器部署和管理微服务。

• 微服务应用的四个设计原则

　　　　当咱们搞清楚了微服务所涉及到的一些概念以后，咱们也清楚的了解到了微服务的好处，那么咱们能够尝试来把本身的应用设计成微服务了，而设计微服务应用，通常要遵循四个原则：

　　　　1.AKF拆分原则

　　　　　　

AKF扩展立方体(参考《The Art of Scalability》)，是一个叫AKF的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，能够将一个单体系统，进行无限扩展。

X 轴 ：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，作个集群加负载均衡的模式。

Z 轴 ：是基于相似的数据分区，好比一个互联网打车应用忽然或了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。

Y 轴 ：就是咱们所说的微服务的拆分模式，就是基于不一样的业务拆分。

　　　　2.先后端分离

　　　　　　先后端分离并非什么稀奇的东西了，作过APP的同窗确定都知道，先后端必然是分离的，在微服务中，不论是web仍是app，先后端都必须分离。

　　　　3.无状态服务

在Java开发中，不少年前就有“有状态bean”和“无状态bean”，原理其实和微服务中的无状态是相似的。通常应用系统中最常出现的有状态：1.session问题；2.本地内存数据缓存；3.一些application级别的常量或者变量等。在微服务架构中，咱们要把这些有状态的东西迁移到分布式缓存中进行存储，例如redis。

　　　　4.Restful通讯

　　　　　　restful在java web开发中已是很经常使用的设计风格了。

• 搭建微服务开发架构

　　　　如下架构图是我在项目开发中设计的，以下图所示：架构中所涉及到到具体组件，在后续博文中在单独详细介绍。

　　　　　　

 

1）web层采用Nginx+keepalived。keepalived经过虚拟VIP作Nginx负载，两台以上Nginx作高可用，同时经过Nginx反向代理Zuul集群。实现高可用，高性能的web层。

2）网关层采用Netflix的Zuul组件。经过Zuul的拦截器实现用户认证，权限管理，流量控制等操做；经过Zuul自带的负载均衡Ribbon和断路器Hystrix以及Zuul的反向代理功能，经过serviceId代理整个微服务集群。

3）业务层根据基础服务，支撑服务，核心业务三大层进行划分，其中核心业务层前期可按照较粗粒度进行切分。全部服务之间经过REST API进行通讯，服务间经过断路器Hystrix保证服务降级以及节点出现不可用状态。

4）服务发现与注册中心经过Eureka实现。作服务器端发现较好。

5）Session共享，身份认证经过集成redis+shiro来实现，可解决分布式系统中Session共享、身份统一认证，权限控制等问题。

6）微服务监控经过Spring Admin集成断路监控器Turbine来实现。链路监控可经过Zipkin聚合各业务通调用延迟数据。

7）配置文件中心经过spring cloud config实现，再配合spring cloud bus实现动态刷新。

8）以上架构图中，并无体现DB，这是由于本项目的特殊性，DB采起了共享的方式（违背了微服务的原则:( ~），你们在设计时，应该每一个服务DB相互独立进行设计比较好。

• 微服务持续集成架构设计

　　　　CI使用Jenkins+Git来实现，架构以下：

　　

• 微服务部署策略

　　　　微服务部署策略通常有以下3种方式：

1.单主机多服务实例模式

    提供一到多台物理或虚拟主机，

    在每一个主机上运行多个服务实例。

　　1）一进程一服务：好比一个tomcat发布一个服务

　　2）一进程多服务：好比一个tomcat发布多个服务

优势：资源利用相对高效；部署服务实例更快；

缺点：由于没有隔离，会由于某个服务有问题致使整个主机异常

　　　　 

 2.单主机单服务实例模式

    每台主机上运行独立的服务实例。这一模式有两种不一样实现

——单虚拟机单服务实例和单容器单服务实例。

  1）单虚拟机单服务实例。

    把每一个服务大包围一个虚拟机镜像，

    相似 Amazon EC2 AMI每一个服务实例就是一台使用

                               此镜像启动的虚拟机，譬如 EC2 实例。

 

  优势：每一个服务实例彻底隔离运行，每一个实例都有固定的 CPU 和内存，

　　　　不会被别的服务占用资源；

　　　　可以充分利用成熟的云基础设施；

  缺点：资源利用率低；

　　　　部署服务的新版本一般很缓慢。

　　　　大量无差异的沉重的工做。

　　　　

 

 2）单容器单服务实例。（Docker）

每一个服务实例运行在自有容器中。容器是操做系统级别的虚拟化机制。将服务快速打包为docker镜像，能够在物理机或虚拟机上运行多个docker

  优势：容器比VM更轻量级，服务彻底隔离，

　　　　打包和启动速度更快；

　　　　容易监控资源；

  缺点：没有虚拟机安全，由于共享了宿主机的操做系统；

　　　　管理容器镜像是一项无差异的繁重工做。

 

　　在Docker日趋成熟的时代，固然仍是选择第三种部署策略，基于Docker，但容器单服务方式。

---

 

• 本章总结

　　本章主要从整体架构角度对微服务整个设计到部署流程进行简单探讨，以后的章节再从开发角度对各个组件进行详细讨论。

　　好了，因为篇幅关系，今天咱们就讨论到这里，欢迎你们讨论和建议；若是感兴趣的话，请关注后续文章：）

　　以上。