作为一名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，单容器单服务方式。
本章总结
本章主要从总体架构角度对微服务整个设计到部署流程进行简单探讨，之后的章节再从开发角度对各个组件进行详细讨论。
好了，由于篇幅关系，今天我们就讨论到这里，欢迎大家讨论和建议；如果感兴趣的话，请关注后续文章：）
以上。
