关于微服务架构特点分析？

随着互联网的不断发展，我们在进行服务器开发组织架构上通常会采用分布式架构方法来进行设计。今天，我们就一起来了解一下，微服务架构都有哪些特点。

InfoQ:你近的QConSanFrancisco提出的一个关键前提是，组织如果要从单体大型应用转变为基于微服务的体系结构就得要打破它们的庞大的整体流程。你能再进一步解释一下吗

RafaelSchloming:对于转变为微服务本身，人们实际上并不怎么关心，他们真正关心的是提升特性的完成速度。为了提升特征的完成速度就必需做出改变，而微服务只是这种改变所产生的一个附属物罢了。

对于组织来说非常常见的一种情况是，当他们发展到一个临界点，增加再多的人也不会提升特性的完成速度。当这种情况发生时，通常是因为组织用于产出特性的结构和/或过程成为了瓶颈，而不是人员的数量。

当一个组织遇到这种障碍，开始调查为什么这些特性似乎花费的时间远远超出了合理的资源，答案往往是，每个特性都需要太多不同团队的协调。

这会发生在两个不同的维度上。你的人员可以按职能划分为团队：产品与开发、质保与运维。你的人员也可以按组件划分:例如，前端与领域模型、搜索索引和消息通知。当单个特性需要跨多个不同的团队进行协调时，交付特性的控制因素是不同团队之间的沟通速度和效率。像这样组织结构的组织实际上是被一个庞大的整体过程所阻碍的，这个过程要求每个特性(在某种程度上)要有许多许多的组织来理解它。

InfoQ:那么如何解决这个问题呢

Schloming:为了把很多人用在一个问题上，你需要把他们分成团队，因为人们不能在非常大的群体中有效地沟通。你这么做的时候，其实就是在做出一系列的权衡。你所营造的是每支团队内部具有高保真的沟通和协调，而团队之间是低保真和相对较差的协调。

为改进一个组织内的特性完成速度，您可以将你的人组织成独立的、跨职能的、自给自足的特性团队，可以从头到尾自主掌控一个完整的特性。这将以两种方式提高特性的完成速度。先，由于不同的职能(产品、开发、质保和运维)都圈定于一个特性内，你就可以自定义该特性区域的流程了，例如，IT培训分享对于一个没有人正在使用的新特性，你的流程就不需要优先考虑其稳定性了。其次，由于该特性所需的所有组件都由同一个团队拥有，因此，要想赶紧推出一个特性，就可以进行更快速有效的沟通和协调。

简单地说，微服务架构就是以业务域或业务功能为边界，将一个大而全的应用拆分为可以独立开发，独立部署，独立测试，独立运行的一组小的应用，并且使用轻量级，通用的机制在这组应用间进行通信。
主流的微服务包括：
1、SpringCloud
Spring Cloud , 来自Spring，具有Spring 社区的强大支撑，还有Netflix强大的后盾与技术输出。Netflix作为一家成功实践微服务架构的互联网公司在几年前就把几乎整个微服务框架栈开源贡献给了社区，这些框架开源的整套服务架构套件是Spring Cloud的核心。
- Eureka:服务注册发现框架；
- Zuul:服务网关；
- Karyon：服务端框架；
- Ribbon：客户端框架；
- Hystrix：服务容错组件；
- Archaius：服务配置组件；
- Servo：Metrics组件；
- Blitz4j：日志组件；
2、Dubbo
Dobbo是一个分布式服务框架，是阿里开放的微服务化治理框架，致力于提高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。其核心部分(官网)
- 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式；
- 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持；
- 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
Dubbo 也是采用全 Spring 配置方式，透明化接入应用，对应用没有任何 API 侵入，只需用 Spring 加载 Dubbo的配置即可，Dubbo 基于 Spring 的 Schema 扩展进行加载。当然也支持官方不推荐的 API 调用方式。
3、lstio
lstio 作为用于微服务聚合层管理的新锐项目，是Google、IBM、Lyft（海外共享出行公司、Uber劲敌），首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。
目前首个测试版是针对Kubernetes环境的，社区宣称在未来几个月内会为虚拟机和Cloud Foundry 等其他环境增加支持。lstio将 流量管理添加到微服务中，并为增值功能（如安全性、监控、路由、连接管理和策略）创造了基础。
- >浪潮边缘微服务器EIS800外表线条流畅，设计低调极简，机箱结构可以组合出单主机、防水主机、数据中心节点各种形态的产品，内部散热模块也可以兼顾主动、被动散热，加速满足多元的部署场景，灵活适应室内、室外、数据中心不同部署环境。

SOA与微服务的区别？

SOA的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。

基于这些基础的服务，可以将业务过程用类似BPEL流程的方式编排起来，而BPEL反映的是业务处理的过程，这些过程对于业务人员更为直观，调整也比hardcode的代码更容易。

当然企业还需要对服务治理，比如服务注册库，监控管理等。

我们知道企业计算领域，如果不是交易系统的话，并发量都不是很大的，所以大多数情况下，一台服务器就容纳将许许多多的服务，这些服务采用统一的基础设施，可能都运行在一个应用服务器的进程中。虽然说是面向服务了，但还是单一的系统。

而微服务架构大体是从互联网企业兴起的，由于大规模用户，对分布式系统的要求很高，如果像企业计算那样的系统，伸缩就需要多个容纳续续多多的服务的系统实例，前面通过负载均衡使得多个系统成为一个集群。但这是很不方便的，互联网企业迭代的周期很短，一周可能发布一个版本，甚至可能每天一个版本，而不同的子系统的发布周期是不一样的。而且，不同的子系统也不像原来企业计算那样采用集中式的存储，使用昂贵的Oracle存储整个系统的数据，二是使用MongoDB，HBase，Cassandra等NOSQL数据库和Redis，memcache等分布式缓存。那么就倾向采用以子系统为分割，不同的子系统采用自己的架构，那么各个服务运行自己的Web容器中，当需要增加计算能力的时候，只需要增加这个子系统或服务的实例就好了，当升级的时候，可以不影响别的子系统。这种组织方式大体上就被称作微服务架构。

微服务与SOA相比，更强调分布式系统的特性，比如横向伸缩性，服务发现，负载均衡，故障转移，高可用。互联网开发对服务治理提出了更多的要求，比如多版本，比如灰度升级，比如服务降级，比如分布式跟踪，这些都是在SOA实践中重视不够的。

Docker容器技术的出现，为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似Nodejs或Spring Boot的技术跑在自己的进程中。可能在几十台计算机中运行成千上万个Docker容器，每个容器都运行着服务的一个实例。随时可以增加某个服务的实例数，或者某个实例崩溃后，在其他的计算机上再创建该服务的新的实例。

如何拆分服务？

要围绕业务模块进行拆分，拆分粒度应该保证微服务具有业务的独立性与完整性，尽可能少的存在服务依赖，链式调用。但是，在实际开发过程中，有的时候单体架构更加适合当前的项目。实际上，微服务的设计并不是一蹴而就的，它是一个设计与反馈过程。因此，我们在设计之初可以将服务的粒度设计的大一些，并考虑其可扩展性，随着业务的发展，进行动态地拆分也是一个不错的选择。

REST的名称"表现层状态转化"中，省略了主语。"表现层"其实指的是"资源"（Resources）的"表现层"。

所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。

客户端用到的手段，只能是>

什么是docker

Docker 最初是 dotCloud 公司创始人 Solomon Hykes 在法国期间发起的一个公司内部项目，它是基于 dotCloud 公司多年云服务技术的一次革新，并于 2013 年 3 月以 Apache 20 授权协议开源，主要项目代码在 GitHub 上进行维护。Docker 项目后来还加入了 Linux 基金会，并成立推动 开放容器联盟（OCI）。

Docker 使用 Google 公司推出的 Go 语言 进行开发实现，基于 Linux 内核的 cgroup，namespace，以及 AUFS 类的 Union FS 等技术，对进程进行封装隔离，属于 *** 作系统层面的虚拟化技术。由于隔离的进程独立于宿主和其它的隔离的进程，因此也称其为容器。最初实现是基于 LXC，从 07 版本以后开始去除 LXC，转而使用自行开发的 libcontainer，从 111 开始，则进一步演进为使用 runC 和 containerd。

Docker 在容器的基础上，进行了进一步的封装，从文件系统、网络互联到进程隔离等等，极大的简化了容器的创建和维护。使得 Docker 技术比虚拟机技术更为轻便、快捷。

下面的比较了 Docker 和传统虚拟化方式的不同之处。传统虚拟机技术是虚拟出一套硬件后，在其上运行一个完整 *** 作系统，在该系统上再运行所需应用进程；而容器内的应用进程直接运行于宿主的内核，容器内没有自己的内核，而且也没有进行硬件虚拟。因此容器要比传统虚拟机更为轻便。



传统虚拟化



Docker

为什么要用docker

对开发和运维（DevOps）人员来说，最希望的就是一次创建或配置，可以在任意地方正常运行。

使用 Docker 可以通过定制应用镜像来实现持续集成、持续交付、部署。开发人员可以通过 Dockerfile 来进行镜像构建，并结合 持续集成(Continuous Integration) 系统进行集成测试，而运维人员则可以直接在生产环境中快速部署该镜像，甚至结合 持续部署(Continuous Delivery/Deployment) 系统进行自动部署。

而且使用 Dockerfile 使镜像构建透明化，不仅仅开发团队可以理解应用运行环境，也方便运维团队理解应用运行所需条件，帮助更好的生产环境中部署该镜像。

特性容器虚拟机 启动秒级分钟级 硬盘使用一般为MB一般为GB 性能接近原生弱于 系统支持量单机支持上千个容器一般几十个

基本概念

我们都知道， *** 作系统分为内核和用户空间。对于 Linux 而言，内核启动后，会挂载 root 文件系统为其提供用户空间支持。而 Docker 镜像（Image），就相当于是一个 root 文件系统。比如官方镜像 ubuntu:1804 就包含了完整的一套 Ubuntu 1804 最小系统的 root 文件系统。

Docker 镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。

镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的 类 和 实例 一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。

前面讲过镜像使用的是分层存储，容器也是如此。每一个容器运行时，是以镜像为基础层，在其上创建一个当前容器的存储层，我们可以称这个为容器运行时读写而准备的存储层为容器存储层。

按照 Docker 最佳实践的要求，容器不应该向其存储层内写入任何数据，容器存储层要保持无状态化。所有的文件写入 *** 作，都应该使用 数据卷（Volume）、或者绑定宿主目录，在这些位置的读写会跳过容器存储层，直接对宿主（或网络存储）发生读写，其性能和稳定性更高。

数据卷的生存周期独立于容器，容器消亡，数据卷不会消亡。因此，使用数据卷后，容器删除或者重新运行之后，数据却不会丢失。

镜像构建完成后，可以很容易的在当前宿主机上运行，但是，如果需要在其它服务器上使用这个镜像，我们就需要一个集中的存储、分发镜像的服务，Docker Registry 就是这样的服务。

一个 Docker Registry 中可以包含多个仓库（Repository）；每个仓库可以包含多个标签（Tag）；每个标签对应一个镜像。

通常，一个仓库会包含同一个软件不同版本的镜像，而标签就常用于对应该软件的各个版本。我们可以通过 <仓库名>:<标签> 的格式来指定具体是这个软件哪个版本的镜像。如果不给出标签，将以 latest 作为默认标签。

Centos安装docker18

常用的docker命令

常用的docker镜像

redis

mysql

将一个单体应用拆分成一组微小的服务组件，每个微小的服务组件运行在自己的进程上，组件之间通过如RESTful API这样的轻量级机制进行交互，这些服务以业务能力为核心，用自动化部署机制独立部署，另外，这些服务可以用不同的语言进行研发，用不同技术来存储数据 。

通过以上的定义描述，我们可以基本确定给出微服务的节特征：

用微服务来进行实践到生产项目中，首先要考虑一些问题。比如下图的微服务业务架构：

在上图图表展示的架构图中，我们假设将业务商户服务A、订单服务B和产品服务C分别拆分为一个微服务应用，单独进行部署。此时，我们面临很多要可能出现的问题要解决，比如：

1、客户端如何访问这些服务？

2、每个服务之间如何进行通信？

3、多个微服务，应如何实现？

4、如果服务出现异常宕机，该如何解决？

以上这些都是问题，需要一个个解决。

在单体应用开发中，所有的服务都是本地的，前端UI界面，移动端APP程序可以直接访问后端服务器程序。

现在按功能拆分成独立的服务，跑在独立的进程中。如下图所示：

此时，后台有N个服务，前台就需要记住管理N个服务，一个服务 下线 、 更新 、 升级 ，前台和移动端APP就要重新部署或者重新发包，这明显不服务我们拆分的理念。尤其是对当下业务需求的飞速发展，业务的变更是非常频繁的。

除了访问管理出现困难以外，N个小服务的调用也是一个不小的网络开销。另外，一般微服务在系统内部，通常是无状态的，而我们的用户在进行业务 *** 作时，往往是跨业务模块进行 *** 作，且需要是有状态的，在此时的这个系统架构中，也无法解决这个问题。传统的用来解决用户登录信息和权限管理通常有一个统一的地方维护管理（OAuth），我们称之为授权管理。

基于以上列出的问题，我们采用一种叫做网关（英文为API Gateway）的技术方案来解决这些问题，网关的作用主要包括：

网关(API Gateway)可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个Nodejs的服务端。他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为 单点故障 点或者性能的瓶颈。

最终，添加了网关(API Gateway)的业务架构图变更为如下所示：

所有的微服务都是独立部署，运行在自己的进程容器中，所以微服务与微服务之间的通信就是IPC（Inter Process Communication），翻译为进程间通信。进程间通信的方案已经比较成熟了，现在最常见的有两大类： 同步调用、异步消息调用 。

同步调用

同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。同步调用的有两种实现方式：分别是 REST 和 RPC

基于REST和RPC的特点，我们通常采用的原则为： 向系统外部暴露采用REST，向系统内部暴露调用采用RPC方式。

异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。需要付出的代价是一致性的减弱，需要接受数据 最终一致性 ，所谓的最终一致性就是只可能不会立刻同步完成，会有延时，但是最终会完成数据同步；还有就是后台服务一般要实现 幂等性 ，因为消息发送由于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）。最后就是必须引入一个独立的 Broker，作为中间代理池。

常见的异步消息调用的框架有：Kafaka、Notify、MessageQueue。

最终，大部分的服务间的调用架构实现如下所示：

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。这就出现了新的问题：

这就是服务的发现、识别与管理问题。解决多服务之间的识别，发现的问题一般是通过注册的方式来进行。

具体来说：当服务上线时，服务提供者将自己的服务注册信息注册到某个专门的框架中，并通过心跳维持长链接，实时更新链接信息。服务调用者通过服务管理框架进行寻址，根据特定的算法，找到对应的服务，或者将服务的注册信息缓存到本地，这样提高性能。当服务下线时，服务管理框架会发送服务下线的通知给其他服务。

常见的服务管理框架有：Zookeeper等框架。

如上的问题解决方案有两种具体的实现，分别是： 基于客户端的服务注册与发现 、 基于服务端的服务注册与发现 。

优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持。

优点是所有服务对于前台调用方透明，一般小公司在云服务上部署的应用采用的比较多。

前面提到，单体应用开发中一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。

因此，当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多，比如说：

---