微服务架构的优势
什么是微服务？
起源:微服务的概念源于 2014 年 3 月 所写的一篇文章“”。文中内容提到：微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
通信方式:每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 API）。
微服务的常规定义:微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务。
把原来的一个完整的进程服务，拆分成两个或两个以上的进程服务，且互相之间存在调用关系，与原先单一的进程服务相比，就是“微服务”。（微服务是一个比较级的概念，而不是单一的概念）
1.3 微服务架构的优势
可扩展性:在增加业务功能时，单一应用架构需要在原先架构的代码基础上做比较大的调整，而微服务架构只需要增加新的微服务节点，并调整与之有关联的微服务节点即可。在增加业务响应能力时，单一架构需要进行整体扩容，而微服务架构仅需要扩容响应能力不足的微服务节点。
容错性:在系统发生故障时，单一应用架构需要进行整个系统的修复，涉及到代码的变更和应用的启停，而微服务架构仅仅需要针对有问题的服务进行代码的变更和服务的启停。其他服务可通过重试、熔断等机制实现应用层面的容错。
技术选型灵活:微服务架构下，每个微服务节点可以根据完成需求功能的不同，自由选择最适合的技术栈，即使对单一的微服务节点进行重构，成本也非常低。
开发运维效率更高:每个微服务节点都是一个单一进程，都专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模团队或者个人完全掌控，易于保持高可维护性和开发效率。
Cloud作为目前最流行的微服务开发框架，不是采用了 Cloud框架就实现了微服务架构，具备了微服务架构的优势。正确的理解是使用 Cloud框架开发微服务架构的系统，使系统具备微服务架构的优势（ Cloud就像工具，还需要“做”的过程）。
1.4 什么是 Boot？什么是 Cloud？
Boot框架是由团队提供的全新框架，其设计目的是用来简化基于应用的初始搭建以及开发过程。框架使用了特定的方式来进行应用系统的配置，从而使开发人员不再需要耗费大量精力去定义模板化的配置文件。
Cloud是一个基于 Boot实现的云应用开发工具，它为基于JVM的云应用开发中的配置管理、服务注册，服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。
1.5 微服务、 Boot、 Cloud三者之间的关系
思想：微服务是一种架构的理念，提出了微服务的设计原则，从理论为具体的技术落地提供了指导思想。
脚手架： Boot是一套快速配置脚手架，可以基于 Boot快速开发单个微服务。
多个组件的集合： Cloud是一个基于 Boot实现的服务治理工具包； Boot专注于快速、方便集成的单个微服务个体； Cloud关注全局的服务治理框架。
二、技术解析
2.1 is jar, is http
Boot通过@n注解标识为 Boot应用程序。所有的应用都通过jar包方式编译，部署和运行。
@n
class {
final = .(.class);
void main([] args) {
.run(.class, args);
(”启动成功！");
每个 Boot的应用都可以通过内嵌web容器的方式提供http服务，仅仅需要在pom文件中依赖-boot-start-web即可，原则上微服务架构希望每个独立节点都提供http服务。
org..boot
-boot--web
2.2 boot Task 任务启动和定时任务
在 Boot需要启动任务时，只要继承接口实现其run方法即可。
@n
class
void run(... ) {
ndler();
在 Boot需要执行定时任务时，只需要在定时任务方法上增加@(cron = “0 15 0 * * ?”)注解（支持标准cron表达式），并且在服务启动类上增加@的注解即可。
@n
@
class {
final = .(.class);
void main([] args) {
.run(.class, args);
(”启动成功！");
// some class
@(cron = "0 15 0 * * ?")
void () {
***
2.3 boot 监控
是 boot提供的对应用系统自身进行监控的组件，在引入-boot-start-web基础上引入-boot--即可。
org..boot
-boot--
2.4 cloud 配置中心
在我们实现微服务架构时，每个微服务节点都需要自身的相关配置数据项，当节点众多，维护就变得非常困难，因此需要建立一个中心配置服务。
Cloud 分为两部分。 Cloud 作为一个服务进程， Cloud File为配置文件存放位置。
2.5 cloud 服务注册中心
服务注册的概念早在微服务架构之前就出现了，微服务架构更是把原先的单一应用节点拆分成非常多的微服务节点。互相之间的调用关系会非常复杂， Cloud 作为注册中心，所有的微服务都可以将自身注册到 Cloud 进行统一的管理和访问（和不同，在AOP原则中选择了OP，更强调服务的有效性）
2.6 cloud Zuul 服务端智能路由
当我们把所有的服务都注册到（服务注册中心）以后，就涉及到如何调用的问题。 Cloud Zuul是 Cloud提供的服务端代理组件，可以看做是网关，Zuul通过获取到可用的服务，通过映射配置，客户端通过访问Zuul来访问实际需要需要访问的服务。所有的服务通过..name做标识，
不同IP地址，相同..name就是一个服务集群。当我们增加一个相同..name的节点，Zuul通过和通信获取新增节点的信息实现智能路由，增加该类型服务的响应能力。
2.7 cloud 客户端智能路由
与 Cloud Zuul的服务端代理相对应， Cloud 提供了客户端代理。在服务端代理中，客户端并不需要知道最终是哪个微服务节点为之提供服务，而客户端代理获取实质提供服务的节点，并选择一个进行服务调用。和Zuul相似，也是通过和（服务注册中心）进行通信来实现客户端智能路由。
2.8 cloud 分布式追踪
2.9 cloud 调用链
2.10 cloud Feign http客户端
Cloud Feign是一种声明式、模板化的http客户端。 使用 Cloud Feign请求远程服务时能够像调用本地方法一样，让开发者感觉不到这是远程方法（Feign集成了做负载均衡）。
把远程服务和本地服务做映射
@(name = "-http", url = "${TP}")
{
@(value = "/api/", = .GET)
query(@("") token);
以调用本地服务的方式调用远程服务
@
;
nfo() {
byte[] = .(( + ":" + ).(.UTF_8));
token = "Basic " + new (, .UTF_8);
.query(token);
2.11 cloud 断路器
三、微服务实践
3.1 我们开发的几个微服务组件—应用管理中心
应用管理中心可以对每个已经注册的微服务节点进行停止，编译，打包，部署，启动的完整的上线操作。
3.2 我们开发的几个微服务组件—数据查询中心
数据查询中心根据地址，端口，命令获取数据信息。
3.3 我们开发的几个微服务组件—微服务健康检测中心
健康检测中心周期性检查每个微服务的状态，当发现有微服务状态处于DOWN或连接超时时，触发报警。
3.4 我们开发的几个微服务组件—定时任务查询中心
// 在子类中拦截
@
class essor , {
***
/**
* Bean 实例化之后进行的处理
*/
( bean, ) {
.(bean, );
bean;
***
// 拦截后获取定时任务注解
***
( bean, ) {
Class = . (bean);
Map = .(,
new .() {
Set ( ) {
Set = s.(,
.class, .class);
(!.() ? : null);
});
if (!.()) {
= .();
for (Map.Entry entry : .()) {
= entry.();
for ( : entry.()) {
key = + ":" + .();
value = .();
.put(key, value);
null;
***
// 获取定时任务后注册
***
void () {
= + ":" + + ":";
try {
/**
* 定时任务
*/
Map infos = ;
for (Entry item : infos.()) {
= + item.();
= item.();
info = new ();
info.put("", );
info.put("", );
info.put("", );
info.put("", "");
(info.());
.( + , info.());
catch ( ex) {
.error("", ex);
***
3.5 微服务的分类
微服务平台组件
公共服务组件
基础服务组件/业务服务组件
