平台微服务技术架构方案

编写目的

平台随着业务的发展、业务模块的拆分、用户量的增长，系统数量增多，调用依赖关系将会变得复杂，为了确保系统高可用、高并发、高扩展的要求，系统的架构将从单体时代甚至SOA时代迁移至微服务时代。根据不同的客户对服务的要求不同，更合理的配置服务资源，能够针对特定服务发布，影响小，风险小，成本低，使服务资源利用率最大化。根据不同服务对系统资源的要求不同，更合理的配置系统资源，能够频繁发布版本，快速交付需求，实现低成本扩容，弹性伸缩，适应云环境，使系统资源利用率最大化，。

当然平台采用微服务的技术架构，系统的复杂度也将上升，将面临服务依赖关系、服务性能监控、全链路日志、容灾、断路器、限流、甚至部署，测试成本、分布式事务和CAP等问题，API服务网关技术的引入恰好解决了上述问题。

API服务网关是工作在不同区域边界上的关键枢纽和屏障，而公共API服务网关则是工作在公有区和私有区边界上的服务网关，是整个平台有机系统中实现服务集成、服务治理、安全监控、和系统提速等功能的至关重要的核心组件之一，基于服务网关的技术实现认证、限流、日志、缓存、熔断等功能，做到网关的统一管理，经过前期调查研究、实验验证和讨论决策，团队领导一致同意采用基于Kong的公共API服务网关解决方案。

本文档旨在明确平台微服务治理技术与API服务网关技术的选型，明确微服务的实施过程与分类治理，梳理微服务的网关应用分类、API命名、采用的HTTP方法、参数列表、参数内容、跨域问题、版本控制、状态码等问题，指导平台微服务模块化的开发，指导微服务与网关的对接集成。

技术选型微服务架构选择单体服务架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用垂直拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的 Web框架(MVC) 是关键。

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。

此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

SOA服务架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

平台随着业务的发展从 All in One 环境就可以满足业务需求（以Java来说，可能只是一两个war包就解决了）；发展到需要拆分多个应用，并且采用MVC的方式分离前后端，加快开发效率；在发展到服务越来越多，不得不将一些核心或共用的服务拆分出来，提供实时流动监控计算等，其实发展到此阶段，如果服务拆分的足够精细，并且独立运行，这个时候至少可以理解为SOA（Service-Oriented Architecture）架构了。

微服务架构

微服务相比于SOA更加精细，更多的以独立的进程的方式存在，互相之间并无影响；微服务提供的接口方式更加通用化，例如HTTP RESTful方式，各种终端都可以调用，无关语言、平台限制；更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合；

微服务与SOA有很多相同之处。两者都属于典型的、包含松耦合分布式组件的系统结构。在围绕着服务的概念创建架构这一方面，微服务提供了一种更清晰、定义更良好的方式。微服务的原则与敏捷软件开发思想是高度一致的，而它与SOA原则的演化的目标也是相同的，则减少传统的企业服务总线开发的高复杂性。两者之间最关键的区别在于，微服务专注于以自治的方式产生价值。但是两种架构背后的意图是不同的：SOA尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。

架构选择总结

功能

SOA

微服务

组件大小

大块业务逻辑

单独任务或小块业务逻辑

耦合

通常松耦合

总是松耦合

公司架构

任何类型

小型、专注于功能交叉的团队

管理

着重中央管理

着重分散管理

目标

确保应用能够交互操作

执行新功能，快速拓展开发团队

综上述内容，平台后期基于公有云的实施部署，实现高可用、松耦合、快速拓展、弹性收缩的服务架构，同时平台的多模块、多服务治理、且各业务模块更加着重分散管理，能够单独实施为客户提供服务。单体服务架构已不在满足服务需求，基于研发团队的规模以及开发模式，明显微服务架构更加适合工作的开展。

微服务框架选型

业界比较成熟的服务框架有很多，比如：Hessian、CXF、Dubbo、Dubbox、Spring Cloud、gRPC、thrift等技术实现，都可以进行远程调用，具体技术实现优劣参考以下分析，这也是具体在技术方案选择过程中的重要依据。

Dubbo

Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。具备以下特性：

透明远程调用：就像调用本地方法一样调用远程方法；只需简单配置，没有任何API侵入；负载均衡机制：Client端LB，可在内网替代F5等硬件负载均衡器；容错重试机制：服务Mock数据，重试次数、超时机制等；自动注册发现：注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者；性能日志监控：Monitor统计服务的调用次调和调用时间的监控中心；服务治理中心：路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡，等手动配置。自动治理中心：无，比如：熔断限流机制、自动权重调整等；Dubbox

Dubbox是当当网的Dubbo扩展版本，本质上和Dubbo没有区别，名字的含义扩展了Dubbo而已。具备以下属性：

支持REST风格远程调用（HTTP + JSON/XML)；支持基于Kryo和FST的Java高效序列化实现；支持基于Jackson的JSON序列化；支持基于嵌入式Tomcat的HTTP remoting体系；升级Spring至3.x；升级ZooKeeper客户端；支持完全基于Java代码的Dubbo配置；Spring Cloud

Spring Cloud完全基于Spring Boot，是一个非常新的项目，2016年推出1.0的release版本，目前Github上更新速度很快. 虽然Spring Cloud时间最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。Spring Cloud 为开发者提供了在分布式系统（配置管理，服务发现，熔断，路由，微代理，控制总线，一次性token，全局琐，leader选举，分布式session，集群状态）中快速构建的工具，使用Spring Cloud的开发者可以快速的启动服务或构建应用．它们将在任何分布式环境中工作，包括开发人员自己的笔记本电脑，裸物理机的数据中心，和像Cloud Foundry云管理平台。在未来引领这微服务架构的发展，提供业界标准的一套微服务架构解决方案。缺点是项目很年轻，很少见到国内业界有人在生产上成套使用，一般都是只有其中一两个组件。相关的技术文档大部分是英文的，案例也相对较少，使用的话需要摸索的时间会长一些。

Motan

Motan是新浪微博开源的一个Java 框架。它诞生的比较晚，起于2013年，2016年5月开源。Motan 在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用。与Dubbo相比，Motan在功能方面并没有那么全面，也没有实现特别多的扩展。用的人比较少，功能和稳定性有待观望。对跨语言调用支持较差，主要支持java。

Hessian

Hessian采用的是二进制RPC协议，适用于发送二进制数据。但本身也是一个Web Service框架对RPC调用提供支持，功能简单，使用起来也方便。基于Http协议进行传输。通过Servlet提供远程服务。通过Hessain本身提供的API来发起请求。响应端根据Hessian提供的API来接受请求。

框架选型总结

功能

Hessian

Montan

rpcx

gRPC

Thrift

Dubbo

Dubbox

Spring Cloud

开发语言

跨语言

Java

Go

跨语言

跨语言

Java

Java

Java

分布式(服务治理)

×

√

√

×

×

√

√

√

多序列化框架支持

hessian

√(支持Hessian2、Json,可扩展)

√

× 只支持protobuf)

×(thrift格式)

√

√

√

多种注册中心

×

√

√

×

×

√

√

√

管理中心

×

√

√

×

×

√

√

√

跨编程语言

√

×(支持php client和C server)

×

√

√

×

×

×

支持REST

×

×

×

×

×

×

√

√

关注度

低

中

低

中

中

中

高

中

上手难度

低

低

中

中

中

低

低

中

运维成本

低

中

中

中

低

中

中

中

开源机构

Caucho

Weibo

Apache

Google

Apache

Alibaba

Dangdang

Apache

平台的总体规划，由Java开发的微服务系统，从开发语言、服务治理、多序列化、多注册中心、管理中心、上手难度等多个层面，综合考量。同时我们基于微服务技术的积累，选择Dubbo为核心技术框架，实现不同类型不同粒度分类的服务治理，由Zookeeper作为服务的注册中心，让多个服务提供者形成一个集群，让服务消费者通过服务注册表获取具体的服务访问地址（ip+端口）去访问具体的服务提供者。

微服务分类微服务分类目标架构必须稳定；服务必须高内聚 - 服务应该实现一小组强相关的功能；服务必须符合开闭原则 - 将一同变更的内容打包在一起，以确保每个更改仅影响一个服务；服务必须松耦合 - 每个服务都可以在不影响客户端的情况下更改实现；服务应该是可测试的；每项服务都小到足以由“两个披萨”团队开发，即一个6-10人的团队；负责一个或多个服务的每个团队必须是自治的 - 团队能够在与其他团队尽量少的协作下，来开发和部署他们的服务。微服务分类原则AKF拆分原则

AKF拆分原则是一个叫AKF的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。

X 轴 ：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，做个集群加负载均衡的模式。

Z 轴 ：是基于类似的数据分区，用户量激增，集群模式撑时按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。

Y 轴 ：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。平台将采用不同的业务拆分模式实施。

前后端分离

前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离。平台前端采用Vue+Element技术实现与后端的物理分离。

无状态服务

无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。

场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。

RESTful通信风格

作为一个原则来讲本来应该是个“无状态通信原则”，我们直接应用一个实践优选的Restful 通信风格。REST API 使用统一资源标识符（URI）来寻址资源。URI 设计范围可以清楚地传达API的资源模型。URI遵循以下原则：

URI中不应包含尾随的斜杠（/）；URI 中的每个字符都会被计入作为资源的唯一标识；正斜杠分隔符（/）必须用于指示层次关系；应使用连字符（ - ）来提高 URI 的可读性；不得在 URI 中使用下划线（_）；URI 路径中首选小写字母；文件扩展名不应包含在 URI 中；

微服务分类设计

平台为实现微服务的分类目标，将遵循微服务分类原则，采用前后端分离技术架构，以不同的业务拆分模式实施, 内部采用Dubbo服务治理，遵循无状态通信原则，外部统一提供RESTful服务。

服务分类治理

服务状态码

序号

状态码

状态消息

1

200

请求成功!

2

201

创建成功!

3

202

更新成功!

4

400

请求的地址不存在或者包含不支持的参数!

5

401

未授权,令牌、用户名、密码错误!

6

403

访问被禁止!

7

404

请求的资源不存在!

8

406

请求的格式不可得!

9

500

服务器内部错误，请联系管理员!

服务错误页

错误页地址/error/error.html

服务接口页

Swagger-ui地址 /server/swagger-ui.html,目前版本不是最新的

微服务实现项目模块化

模块化是个一般概念，这一概念可以让软件按模块单独开发，各模块通常都用一个标准化的接口来进行通信。平台包含多个子系统，每个子系统包含多个业务模块，在多人协同开发时，因项目模块较多，为了方便日后的代码维护和管理，我们会将每个开发人员的工作细分到具体的功能和模块上。随着项目的不断扩大，模块也会越来越多，后续会更加难以维护和扩展，为了应对这种情况我们采用微服务架构的方式进行开发。

平台中使用Maven来构建，Maven模块化项目管理，适用于一些比较大的项目，通过功能的模块拆分，实现代码的解耦合，便于代码的复用和维护及管理。通过一个POM文件来管理项目依赖，只要在POM中加入想要的Jar包依赖，Maven会在本地仓库中查找依赖包。

平台中总体应用Maven模块化设计思想，内部采用Dubbo服务治理，外部统一提供RESTful服务，把系统划分外多个模块有助于将耦合减至最低，让代码维护更加简单，更有利于任务分工，后期维护，易扩展，模块还可以独立成服务单独部署