标签：架构 art 虚拟机 管理 服务框架 建议 兴趣 轻量 网络
作为一名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，但容器单服务方式。
标签：架构 art 虚拟机 管理 服务框架 建议 兴趣 轻量 网络
原文地址：https://www.cnblogs.com/yyqailaopo/p/9074540.html
