微服务，云架构，DDD，SpringCloud，Docker总体概述

一、什么是微服务架构？

       近年来，在软件开发领域关于微服务的讨论呈现出火爆的局面，越来越多的人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发，和当初的Servlet规范一样，被认为是IT软件架构的未来方向。
       那么，什么是微服务架构呢？简单说，微服务是系统架构上的一种设计风格，就是将一个完整的应用（单体应用）按照一定的拆分规则（后文讲述）拆分成多个不同的服务，每个服务都能独立地进行开发、部署、扩展。由于有了轻量级的通信协议作为基础，所以这些微服务可以用不同的编程语言来实现。服务与服务之间通过注入RESTful api(同步调用)或消息(异步调用)的方式来调用。

单体应用和微服务的区别：

单体应用：我们描述某一个复杂的业务场景需求时，我们会将项目范围主要的三个部分：数据库，服务端处理，前端展示。在业务发展前期的时候，由于所有的业务逻辑都在一个应用中，所以开发、测试、部署比较容易且方便。但是随着企业的发展，业务规模的扩大，系统应对各种不同的业务场景会不断的为该单体项目不停的新增业务模块，为了应对不同业务场景下的技术支持，不断的扩大项目。终有一天，项目变得臃肿异常。这时候，改变一个需求，为了部署上线，往往会影响到其他的功能。此时，部署难度呈指数上升，维护成本越来越大。

微服务：为了解决单体应用臃肿后不可维护的问题，微服务架构应运而生。它将不同的业务模块以项目的形式呈现出来，每个项目都是可以单独运行，部署的。每个服务都是运行在自己的线程中，所以服务与服务之间是隔离互不侵犯的。在实践微服务之前，虽然我们享用到了它的各种好处，但是不免会遭到在单体应用中没有的新挑战。

微服务的新挑战：

1.服务的拆分原则

2.分布式技术选型

3.运维的挑战

接下来，楼主在从这三个方面对微服务的新挑战做一个大概的概括。结尾有彩蛋(#^.^#)

二、当DDD遇上微服务

领域驱动设计（Domain-Driven Design，DDD）是一项很伟大的技术，它并不是一项新技术，而是九十年代的时候就给提出来的一种分析解决问题的方式，领域模型是说明问题域里（对建模者来说）有意义的领域类，它是面向对象分序的时候要创建的最重要的工作（必须说明，用例虽然也是一个重要的分析工作，但它并不是面向对象的，它是强调的概念的过程视图）。

在用DDD来切分微服务的时候，我们要明确一下两个概念：

1、问题域：现实世界中系统所要解决问题的领域为“问题域”，如“银行业务”属于“银行的问题域”。

2、领域建模：

     我们设计一个系统，总是希望它能解决一些问题，这些问题总是会映射到现实问题和概念。

     对这些问题进行归纳、分析的过程就是领域建模（这个域，指的就是问题域）。

为什么建立一个领域模型是必要的：
1、通过建立领域模型能够从现实的问题域中找到最有代表性的概念对象
2、并发现出其中的类和类之间的关系，因为所捕捉出的类是反馈问题域本质内容的信息。
      经典的面向对象的分析或调研的步骤，是把一个相关的领域，分解为单个领域类或者对象（是一个我们能够理解的概念）。
      领域模型是领域类或者是我们感兴趣的现实对象的可视化表示。
它们也被称之为：概念模型、领域对象模型、分析对象模型等。
在UML中，领域模型是不定义操作（方法）的一组类图来说明，它主要表达：
1、领域对象或者领域类
2、领域类之间的关联
3、领域类的属性

相对于传统MVC架构中，服务层中的事件主要是增删改查四个，没有其他过多复杂的事件描述。而在DDD中，服务层（领域服务）则是对传统架构中的Service的充血分析。在这个服务层里面，它不仅会记录增删改查四个事件，还会有产生其他的事件监听。为了满足DDD中的事件需求，CQRS（后续的博客会给大家介绍）架构逐渐被DDD设计者重视。

三、技术选型

1、为什么选择SpringCloud

近几年虽然微服务的概念异常火热，但是回头看看，其实微服务早在前几年就已经被提及了。无数的架构师和开发者在这方面做了很多的努力，并且活跃在他们的社区里面，为新技术的迭代不断的做出自己的贡献。其中不乏国内互联网公司的杰出贡献：

目前Spring Cloud在国内的知名度并不高，有些甚至还不知道该项目的存在。可能这也与国内阿里巴巴开源服务治理框架Dubbo有一定的关系，除了Dubbo本身较为完善的中文文档之外，不少科技公司的架构师均出自阿里系。虽然国内有着Dubbo一统微服务的趋势，但是Spring Cloud作为Spring Source的产物，Spring社区的强大背书可以说是Java企业界最有影响力的组织了，除了Spring Source之外，还有Pivotal和Netfix是其强大的后盾与技术输出。从技术文档的完整性，社区活跃度，架构的完整性而言，SpringCloud可以说是完胜Dubbo。前段时间Dubbo放弃维护了，虽然这段时间虽然阿里又开始维护起来了，但是社区活跃度技术的迭代速度依旧赶不上SpringCloud。

2、SpringCloud技术概括

Spring Cloud是基于Spring Boot的一整套实现微服务的框架。他提供了在分布式系统开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。最重要的是，跟spring boot框架一起使用的话，会让你开发微服务架构的云服务非常好的方便。

Spring Cloud包含了非常多的子框架，其中，Spring Cloud Netflix是其中一套框架，由Netflix开发后来又并入Spring Cloud大家庭，它主要提供的模块包括：服务发现、断路器和监控、智能路由、客户端负载均衡等。一下给大家概括常见的几个组件

a、服务发现（eureka）：服务注册和发现，它提供了一个服务注册中心、服务发现的客户端，还有一个方便的查看所有注册的服务的界面。 所有的服务使用Eureka的服务发现客户端来将自己注册到Eureka的服务器上。eureka整体架构图

服务消费者：服务消费者同时也是服务的提供者。在服务启动的时候，它会向eureka发送一个rest请求，eureka会返回给一个Map集合的元数据类型。同时每隔30秒重新发送一次请求，来更新eureka上面的服务实例。

服务的提供者：在服务启动的时候会发送一个rest请求到eureka服务器，注册并携带自己的一些元数据。

服务调用：服务消费者在获得服务清单后，会根据服务id来获取具体的服务实例(如果服务实例大于2的话，由ribbon来选择具体的服务实例)，来拼接成一个新的网络地址。

服务同步：这里维护了两个注册中心，所有注册到服务器上面的服务同时会被这两个节点维护。客户端可以通过任意注册中心获得某一个注册到eureka上面的服务节点。默认情况下注册中心每隔90秒挂起一个坏死节点，等待节点的恢复。

b、客户端的负载均衡（Ribbon）：主要提供客户侧的软件负载均衡算法。提供一系列完善的配置选项，比如连接超时、重试、重试算法等。

c、声明式服务调用（Feign）：一种声明式、模板化的HTTP客户端。在Spring Cloud中使用Feign, 我们可以做到使用HTTP请求远程服务时能与调用本地方法一样的编码体验，开发者完全感知不到这是远程方法，更感知不到这是个HTTP请求。

d、服务路由（Zuul）：当一个应用调用一个或更多的后端服务的时候，我们可以用Spring Cloud创建一个Zuul代理减少开发是非常常见的例子。所有的外部请求由Zuul来转发，既屏蔽了内部服务的调用细节，又保证了服务的安全性，只对外提供一个公用的端口号。

e、分布式配置服务器（Config）：为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。在spring cloud config 组件中，分两个角色，一是config server，二是config client。

f、熔断器(Hystrix)：Hystrix主要为了解决服务的容错性，通过服务隔离、熔断(也可以称为断路)、降级等手段控制依赖服务的延迟与失败。

当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open).。这时所有请求会直接失败而不会发送到后端服务.，断路器保持在开路状态一段时间后(默认5秒)，自动切换到半开路状态(HALF-OPEN)。这时会判断下一次请求的返回情况，如果请求成功， 断路器切回闭路状态(CLOSED)， 否则重新切换到开路状态(OPEN)。 Hystrix的断路器就像我们家庭电路中的保险丝，一旦后端服务不可用，断路器会直接切断请求链， 避免发送大量无效请求影响系统吞吐量，并且断路器有自我检测并恢复的能力。

turbine是聚合服务器发送事件流数据的一个工具，hystrix的监控中，只能监控单个节点，实际生产中都为集群，因此可以通过
turbine来监控集群下hystrix的metrics情况，通过eureka来发现hystrix服务。

熔断器的监控页面：

四、运维的挑战

1、docker简介

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）。几乎没有性能开销，可以很容易地在机器和数据中心中运行。最重要的是,他们不依赖于任何语言、框架包括系统。

由于众多新颖的特性以及项目本身的开放性，Docker在不到两年的时间里迅速获得诸多厂商的青睐，其中更是包括Google、Microsoft、VMware等业界行业领导者。Google在今年六月份推出了Kubernetes，提供Docker容器的调度服务，而今年8月Microsoft宣布Azure上支持Kubernetes，随后传统虚拟化巨头VMware宣布与Docker强强合作。今年9月中旬，Docker更是获得4000万美元的C轮融资，以推动分布式应用方面的发展。

和传统的虚拟机不一样，docker容器更像是一个应用，它不会过多的吃宿主机的性能。在一台宿主机上面最多能开三四个虚拟机的时候宿主机性能就有点吃紧，但是运行几十个docker容器（应用）却是轻轻松松的。

2、为什么docker适合微服务，从以下几个方面来解释

a、隔离抽象可移植性

      我们可以从头建立一个分布式应用，根据应用的需求定制环境，并复用在所有Docker主机上。还可以省去不重要安装，环境依赖，将环境改变控制在容器内，从而保持操作系统的纯净。

b、轻量级

     docker轻量级，开销很少，这使得它成为一个开发immutable infrastructure的绝佳工具，并且所有组件都很容易被替代。使用Docker 可以在同一台主机上运行更多的服务和应用，不会产生性能损失和额外的容量。

c、版本化的镜像

      docker通过docker镜像来交付环境，你可以用Docker的强大的tag机制指定你的镜像的版本。这意味着你可以版本化你的整个微服务环境，不管你的应用s用是Java、Python、Ruby还是其它完全独立于主机操作系统的语言写的，都可以拥有一个同质的打包系统。真正实现一处打包，到处运行。

d、可复用

      docker组件是可以复用的。在其设计之处，我们可以设计一个基本的docker镜像，作为其他镜像的基础。

e、可测试

       Dockerfile描述了docker的环境，以及能够使我们的应用运行于其上的必要的步骤。每次Docker构建的过程，都是对这个步骤的测试，测试其能否为我们的应用程序执行创建一个完美的运行环境。

g、DevOps的思维方式

       得益于上述几点，开发团队更容易从传统思维过渡到DevOps的思维方式，关注完整的软件交付生命周期。Docker可以将IT运维部门从一个繁忙的、简易的交付批准/拒绝导向的团队，变成一个有效率的，交付授权的部门，而且开发人员可以在容器内定制自己的运行环境，同时不会影响其他应用。

以上就是楼主这次大致概括的一个主要内容啦，如有什么说得不对的地方，欢迎各路大佬前来指点，只求轻点，毕竟我也还在学习中o(╥﹏╥)o

以上概括中的详情和楼主在实践微服务遇到的史前巨坑，会在后面的博客里面持续更新的，谢大家关注，撒花^_^~

最后...人家这么可耐，你确定不关注一波嘛✪ω✪