一、概述
微服务架构是一种新的软件体系设计形式，提倡将应用系统按照一定的原则将大系统拆分成一系列细小的服务，每个服务只需要专注于一个单一的业务功能即可，并且服务之间可以互相独立运行，采用轻量级API进行通信，来满足业务和用户的需求。
微服务的架构实现前后端分离，将表现层组件从业务和数据访问组件中分离出来。
1.前端技术主要采用了Angular4：
（1）Angular4实现一套框架，多种平台，复用代码和技能来构建适用于所有平台的应用
（2）通过Web Worker和服务端渲染，达到在如今(以及未来）的Web平台上所能达到的最高速度
（3）有效掌控可伸缩性：基于RxJS、Immutable.js和其它推送模型，能适应海量数据需求
2.业务逻辑和后台服务采用了Spring Cloud：
（1）Spring Boot实现了应用配置的简单和易用
（2）Maven/Gradle配置，用来实现应用构建、测试和运行
（3）Spring Security实现用户认证机制
（4）应用程序接口的RESTful由Spring MVC + Jackson实现
（5）准实时通信方式由Spring Websocket来支持
（6）服务注册与发现由Netflix Eureka或者CONSUL实现
（7）API网关由Zuul 提供动态路由，具有监控，弹性，安全等先进的前沿技术
（8）部分微服务间通信由RabbitMQ的发布和订阅消息系统来承担
二、基于Angular4的前端技术
Angular是一个构建客户端应用的框架，该框架由多个库文件(libraries)组成，使用HTML和JavaScript或者可以被编译成JavaScript（比如TypeScript）的语言。Angular 需要基于这些组件构建应用：编写有Augular的指令的HTML模板（templates），编写组件类（component classes）来管理这些模板，在服务（services）中添加应用逻辑，再把这些组件和服务封装在模块（modules）中。
1.Modules 模块
Angular 应用是模块化的，它拥有自己的模块化系统，称作 NgModule。一个 NgModule 就是一个容器，用于存放一些内聚的代码块，这些代码块专注于某个应用领域、某个工作流或一组紧密相关的功能。 它可以包含一些组件、服务提供商或其它代码文件，其作用域由包含它们的 NgModule 定义。 它还可以导入一些由其它模块中导出的功能，并导出一些指定的功能供其它 NgModule 使用。
每个 Angular 应用都至少有一个 NgModule 类，也就是根模块，它习惯上命名为 AppModule，并位于一个名叫 app.module.ts 的文件中。引导这个根模块就可以启动你的应用。
虽然小型的应用可能只有一个 NgModule，不过大多数应用都会有很多特性模块。应用的根模块之所以叫根模块，是因为它可以包含任意深度的层次化子模块。
2.组件 Components
组件控制屏幕上被称为视图的一小片区域（即视图），为视图提供支持。
组件通过一些由属性和方法组成的API与视图交互：在类里定义组件的应用逻辑，这个类通过API的属性和方法与视图交互。
3.模板 Templates
组件自带的模板中可以定义组件的视图：模板以HTML形式存在，它告诉Angular如何去渲染组件。模板会把 HTML 和 Angular 的标记（markup）组合起来，这些标记可以在 HTML 元素显示出来之前修改它们。 模板中的指令会提供程序逻辑，而绑定标记会把你应用中的数据和 DOM 连接在一起。
4.元数据 Metadata
组件的元数据告诉 Angular 到哪里获取它需要的主要构造块，以创建和展示这个组件及其视图。 具体来说，它把一个模板（无论是直接内联在代码中还是引用的外部文件）和该组件关联起来。 该组件及其模板，共同描述了一个视图。
5. 数据绑定 Data binding
Angular 支持双向数据绑定，这是一种对模板中的各个部件与组件中的各个部件进行协调的机制。
6. 指令 Directives
Angular 的模板是动态的：当 Angular 渲染它们的时候，会根据指令给出的指示对 DOM 进行转换。组件从技术角度上说就是一个指令，但是由于组件对 Angular 应用来说非常独特、非常重要，因此 Angular 专门使用一些面向模板的特性扩展指令：
（1）结构型指令通过添加、移除或替换 DOM 元素来修改布局；
（2）属性型指令会修改现有元素的外观或行为。 在模板中，它们看起来就像普通的 HTML 属性一样，因此得名“属性型指令”。
7. 服务 Services
服务（Service）是一个很宽泛的类别，包括应用需要的任何值、函数、或者功能。
8. 依赖注入 Dependency injection
依赖注入是提供类的新的实例的一种方式，这个实例有它所需的所有依赖。大多数依赖都是服务。 Angular 使用依赖注入来为新的组件提供它们所需要的服务。
三、基于Spring Cloud的后端技术
1. 服务注册与发现 - Eureka
Eureka是微服务器的注册和定位服务器，负载平衡和容错能力。Eureka的工作是注册现有微服务的不同实例，其位置，条件，元数据...
每个微服务器将在启动时与Eureka服务器进行通信，以便通知它可用的位置，其元数据...。以这种方式，Eureka将把所有生态系统微服务的信息保存在其中。新的微型服务将继续每隔30秒通知Eureka的状态，我们称之为“心跳”。如果经过3个时期，Eureka还没有收到这个微服务器的通知，它将从注册表中消除。同样，一旦Eureka收到三个通知，它将再次考虑可用的服务。
Eureka的每个客户端也可以恢复注册表，以便找到需要与之通信的其他微服务器。注册表的信息存储在客户端的缓存中。Eureka可以配置为以群集模式工作，其中各种“对等”实例将交换其信息。这与存储在客户端缓存中的注册表信息一起使Eureka具有高容错能力。
2. 客户端负载均衡 - Ribbon
Ribbon是一个客户端负载平衡器，可以很好地控制HTTP和TCP客户端的行为。与传统的负载平衡器相比，每次线上调用都不需要额外的跳转 - 可以直接与所需的服务联系。
开箱即用，它原生地集成了Spring Cloud和服务发现。Eureka客户端提供可用服务器的动态列表，因此Robbin可以在它们之间进行平衡。
3. 网关 – Zuul
应用接口网关是基于Zuul实现的。Zuul是一种“前沿服务”，允许动态路由，负载平衡，监控和请求安全。 在实际意义上，Zuul是由过滤器组成的服务器，每个过滤器都面向诸如前面提到的功能。
在微服务架构中，Zuul通常将被配置为生态系统的入口点，并负责路由，平衡，安全等等微服务接收的请求。
发送到Zuul的每个请求都将通过过滤器，根据请求的特点，可以例如拒绝它用于安全问题，将其注册到监视的目的，并将其重定向到特定的微服务实例等等，根据配置的过滤器或我们实现的过滤器。
Zuul默认使用Ribbon，以便通过Eureka找到它将重定向它将在“Hystrix Command”中运行的请求的微服务实例，整合所有架构的组件，充分利用Spring Cloud生态系统提供的所有优势。
Zuul还允许我们通过属性配置到微服务器的路由，以便在Eureka中注册的名称不必一定要调用微服务器。 但是，这种路由功能不会像Ribbon和Hystrix那样使用架构的其他元素。
基于Zuul实现的应用接口网关的功能特性如下：
（1）它提供了一个能够快速反应的系统，根据可能面临的不同挑战性情况改变其行为：这是通过Zuul组成的不同过滤器实现的。
（2）它提供了一系列过滤器来处理不同的情况：认证和安全过滤器，监控过滤器，动态路由过滤器，负载测试过滤器，资源管理或静态响应过滤器，多区域管理过滤器...
（3）它允许实现个性化过滤器并上传这些，而无需重新启动服务器，这允许负载重新平衡，请求重定向和取消实时更改应用程序的行为，而无需重新启动服务器...这是由于Zuul的编译和运行过滤器而不停止应用程序。 因此，例如，可以实现一个过滤器，并且从某一时刻将少量请求重定向到具有新版本的微服务实例，以便您可以测试它。
（4）当所有请求都通过Zuul移动到微服务器生态系统时，它可以执行诸如CORS管理，认证这样的常见任务，这样就不必在每个微服务中稍后执行。
4. 服务熔断和降级 – Hystrix
微服务之间存在错综复杂的依赖关系，一次请求可能会依赖多个后端服务，在实际生产中这些服务可能会产生故障或者延迟，在一个高流量的系统中，一旦某个服务产生延迟，可能会在短时间内耗尽系统资源，将整个系统拖垮，因此一个服务如果不能对其故障进行隔离和容错，这本身就是灾难性的。我们的微服务架构中使用了Hystrix组件来进行容错处理。Hystrix是Netflix的一款开源组件，它通过熔断模式、隔离模式、回退（fallback）和限流等机制对服务进行弹性容错保护，保证系统的稳定性。
（1）熔断模式：熔断模式原理类似于电路熔断器，当电路发生短路时，熔断器熔断，保护电路避免遭受灾难性损失。当服务异常或者大量延时，满足熔断条件时服务调用方会主动启动熔断，执行fallback逻辑直接返回，不会继续调用服务进一步拖垮系统。熔断器默认配置服务调用错误率阀值为50%，超过阀值将自动启动熔断模式。服务隔离一段时间以后，熔断器会进入半熔断状态，即允许少量请求进行尝试，如果仍然调用失败，则回到熔断状态，如果调用成功，则关闭熔断模式。
（2）隔离模式：Hystrix默认采用线程隔离，不同的服务使用不同的线程池，彼此之间不受影响，当一个服务出现故障耗尽它的线程池资源，其他的服务正常运行不受影响，达到隔离的效果。例如我们通过andThreadPoolKey配置某个服务使用命名为TestThreadPool的线程池，实现与其他命名的线程池隔离。
（3）回退（fallback）：fallback机制其实是一种服务故障时的容错方式，原理类似Java中的异常处理。只需要继承HystixCommand并重写getFallBack()方法，在此方法中编写处理逻辑，比如可以直接抛异常（快速失败），可以返回空值或缺省值，也可以返回备份数据等。当服务调用出现异常时，会转向执行getFallBack()。有以下几种情况会触发fallback：
1) 程序抛出非HystrixBadRequestExcepption异常，当抛出HystrixBadRequestExcepption异常时，调用程序可以捕获异常，没有触发fallback，当抛出其他异常时，会触发fallback；
2) 程序运行超时；
3) 熔断启动；
4) 线程池已满。
（4）限流：限流是指对服务的并发访问量进行限制，设置单位时间内的并发数，超出限制的请求拒绝并fallback，防止后台服务被冲垮。
Hystix使用命令模式HystrixCommand包装依赖调用逻辑，这样相关的调用就自动处于Hystrix的弹性容错保护之下。调用程序需要继承HystrixCommand并将调用逻辑写在run()中，使用execute()（同步阻塞）或queue()（异步非阻塞）来触发执行run()。
5. 动态配置中心 – Cloud-config
Config Server是分布式系统的配置服务器。其工作是存储生态系统的微服务配置属性。
默认情况下，Cloud-config将配置属性存储在git中。在启动时，微服务器将向云配置服务器查询相关属性，该服务器将从git存储库中下载它们。整个过程透明地进行，开发额外的实现代码。
传统上，属性文件将以{microservice} - {profile}格式命名。{yml | properties}其中'microservice'是所述微服务的标识符和“配置文件”的一个Spring配置文件
总结Cloud-config的功能和优点如下：
（1）Cloud-config与Eureka集成，以便在微服务启动时，如果是Eureka客户端，它将向Eureka服务器询问配置服务器的位置，并要求其配置。
（2）将配置存储在git仓库中可以让我们不仅拥有一个集中的配置存储库，而且还可以存储它。此外，cloud-config增加了与git集成的功能，允许我们查看不同的分支配置。
（3）它允许我们管理不同环境的配置，标记它并通过标签进行查询。
（4）它为属性的值提供可选加密。
（5）当与clound-config集成时，某些Spring注释的存在允许我们重新创建bean并重新启动整个Spring上下文。这允许微服务器适应性能的变化。
6. 分布式跟踪服务
在微服务架构中，众多的微服务之间互相调用，如何清晰地记录服务的调用链路是一个需要解决的问题。同时，由于各种原因，跨进程的服务调用失败时，运维人员希望能够通过查看日志和查看服务之间的调用关系来定位问题，而Spring cloud sleuth组件正是为了解决微服务跟踪的组件。
