微服务架构技术规范第一版v终审稿)

微服务架构技术规范第

一版V

公司内部档案编码：[OPPTR-OPPT28-OPPTL98-OPPNN08]

微服务架构技术规范（试行稿）

1总则

目前研发中心的后台开发中，基于Java/Spring MVC/Spring Boot框架开发，每个部门引入的支撑组件却各异，缺乏统一性，甚至每个部门都维护着一堆非业务组件，影响开发人员对快速变化业务支持的专注性。这套方案的具有较好的可扩展性、可维护性、及良好的代码风格，可以为公司各类型的应用开发提供统一、通用、而强大的基础架构，完全能支持公司所有后台服务沉淀和演化出一个稳健企业中台。

2适用范围

本规范适用于创维数字本部及各分子公司，在使用微服务技术架构进行系统开发时，需遵循此技术规范

3微服务概述

3.1微服务定义

什么是微服务

1．微服务 - 也称为微服务架构 - 是一种架构风格，它将应用程序构建为一组服务

2．高度可维护和可测试

3．松散耦合

4．可独立部署

5．围绕业务能力进行组织。

6．微服务架构支持大型复杂应用程序的持续交付/部署。它还使组织能够发展其技术堆栈。

ChrisRichardson 世界着名软件大师

3.2使用微服务

传统的单体服务，或者模块化不彻底的项目可能存在以下弊端：1．团队职责不清晰

2．构建和部署耗时长

3．全量部署耗时长、影响范围广

4．单体只能按整体横向扩展，无法分模块垂直扩展

5．受技术栈限制，团队成员使用同一框架和语言

6．升级和变革技术框架变得困难

随着软件行业的发展和演变，服务器软件进入了微服务化阶段。对服务的可维护性、可扩展性、可用性这些维度更加让从业人员关注。而微服务化正是解决这些观注的良好的解决方案。所以微服务化正是软件发展演化的结果。在新的目项目应该微服务化解决方案。微服务化的程度可以具体项目具体场景决定。

4开发规范

4.1基本理念

4.1.1无状态服务(Stateless)

无状态就是一次操作，不能保存数据。

在编程层面，无状态对象(Stateless Bean)，就是没有实例变量的对象.不能保存数据，是不变类，是线程安全的。比如Java开发中的EJB, Servlet, Spring MVC， Spring Service都是无状态的。

HTTP 也是一种不保存状态，无状态（stateless）协议。HTTP 协议自身不对请求和响应之间的通信状态进行保存。也就是说在 HTTP 这个级别，协议对于发送过的请求或响应都不做持久化处理。

JWT 也无状态的Token 机制，不需要在服务端存储session信息，因为Token 自身包含了所有用户的相关信息。

Kubernetes中stateless服务也是一种无状态服务，功能强大，易于扩展和发布。

所以无状态是一种非常有价值的架构设计理念。

4.1.2幂等性

是指任意多次执行所产生的影响，与一次执行的影响相同。一个拥有幂等性设计的接口，保证无论一次或多次来调用接口，都能够得到相同的结果。在微服务场景中，幂等有助于系统的可靠性，易于实现重试机制、易于实现缓存系统的设计。

4.2数据请求规范

4.2.1URL规范

针对目前url 使用不规范，提出以下建议。

一般域名后面建议就三层：

采用子域名区分请求是amdin或app的, 不同子域名采用不同ip，入口隔离。

url 字符串中不区分amdin或app，但目前的header可以区分不同业务端，同时可用于控制访问权限。

controller代码中，admin/app放到不同的controller文件中。但RequestMapping不用区分是admin，还是app的功能。

4.2.2REST

要遵循Restful 方式（增删改查对应Post, Delete, Put, Get）的接口定义，所有的get请求必须幂等。

幂等就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。分布式环境下各个服务相互调用, 所以尽可能提供幂等性性接口。

对外接口一般都是http接口，最好根据Http方法的语义来发放请求。对于资源的具体操作类型，由HTTP动词表示。常用的HTTP动词有下面五个：

GET（SELECT）：从服务器取出资源（一项或多项）。

POST（CREATE）：在服务器新建一个资源。

PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。DELETE（DELETE）：从服务器删除资源。

Get/ Delete 采用查询字符串请求。

Post /Put请求和响推荐都采用Json格式。一个Json返回的格式举例如下：

返回成功状态 200 OK ...

{

"CODE":200,

"SUCCESS": TRUE,

"DATA":{},

"MSG":"操作成功"

}

4.3安全

4.3.1HTTPs

HTTPs 可以保障数据的保密性、完整性、身份校验安全性，所以应该实施全站HTTPs化。随着HTTP-2、HTTP-3技术的出现HTTPs的传输效率也有了极大的提高。

4.3.2OAuth2

是开放授权的一个标准，旨在让用户允许第三方应用去访问改用户在某服务器中的特定私有资源，而可以不提供其在某服务器的账号密码给到第三方应用

4.3.3JWT

JWT提供了一种用于发布接入令牌（Access Token),并对发布的签名接入令牌进行验证的方法。令牌（Token）本身包含了一系列声明，应用程序可以根据这些声明限制用户对资源的访问。

4.3.4OpenID Connect

它在OAuth2上构建了一个身份层，是一个基于OAuth2协议的身份认证标准协议。OpenID Connect是OAuth 协议之上的简单身份层，用 API 进行身份交互的框架，允许客户端根据授权服务器的认证结果最终确认用户的身份，以及获取基本的用户信息；它支持包括Web、移动、JavaScript在内的所有客户端类型；它是可扩展的协议，允许你使用某些可选功能，如身份数据加密、OpenID提供商发现、会话管理。

4.4配置中心

一般来说，测试环境的程序和正式环境的一个重要的差别，是配置不同。所以运维相关的配置、程序参数外置，也符合无状态服务的理念，做到测试环境、正式环境一个部署包。

所以程序配置，应该存放在配置中心集中管理。

4.5服务注册中心

注册中心最本质的功能可以看成是一个Query函数 Si = F(service-name)，以 Service-Name 为查询参数，Service-Name 对应的服务的可用的 Endpoints (ip:port) 列表为返回值。

注册中心机制解耦了服务的提供者和服务的使用者，是微服务的关键设计模式。

4.6API GateWay

API 网关对外采用门面设计模式，实现上采用责任链设计模式，是微服务的关键设计模式。

4.7服务通讯

推荐采用Http Rest & JSON方式做服务间通讯，简单也易于调试。随着基于UDP协议的使用，传输效率也会更好。

4.8流量控制

微服务中由于模块较多，网络中因某些原因，有时会出现流量热点，甚于出现拖垮整个集群的可能。我们不能束手无策，所以微服务集群内流量控制上非常必要。目前流量控制推荐使用Alibaba Sentinel，它支持丰富的应用场景、完备的实时监控、广泛的开源生态，可以很方便大家接入。

4.9链路跟踪

当业务模块间调用关系比较复杂时，应引入链路跟踪功能。

5Base Project项目

在微服务的实践中，我们不需要从头构建去构建一个微服务的体系，所以选择一个合适的BaseProject项目，会使大家对微服务使用有一个良好的开端，有利代码风格的统一、有一个较高的起点、以利于微服务的实施。

推荐大家使用Bladex项目，基于该项目完成微服务化实施。

6部署和运维

6.1程序Kubernetes化

Kubernetes和Docker，它是现代微服务设施的主力。推荐生产环境采用kubernetes部署微服务。

6.2数据库Kubernetes化

如果是公有云，数据库一般建议采用公有云RDS、如果是私有云一般数据库部署外置于Kubernetes。目前MySQL等数据库上Kubernetes, 还不是主流方案。