微服务架构技术规（试行稿）
1 总则
目前研发中心的后台开发中，基于Java/Spring MVC/Spring Boot框架开发，
每个部门引入的支撑组件却各异，缺乏统一性，甚至每个部门都维护着一堆非业
务组件，影响开发人员对快速变化业务支持的专注性。
这套方案的具有较好的可扩展性、可维护性、及良好的代码风格，可以为公司各
类型的应用开发提供统一、通用、而强大的基础架构，完全能支持公司所有后台
服务沉淀和演化出一个稳健企业中台。
2 适用围
本规适用于创维数字本部及各分子公司，在使用微服务技术架构进行系统开发
时，需遵循此技术规
3 微服务概述
3.1 微服务定义
什么是微服务？
1．微服务 - 也称为微服务架构 - 是一种架构风格，它将应用程序构建为
一组服务
2．高度可维护和可测试
3．松散耦合
4．可独立部署
5．围绕业务能力进行组织。
6．微服务架构支持大型复杂应用程序的持续交付/部署。 它还使组织能够
发展其技术堆栈。
Chris Richardson 世界著名软件大师
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.1 URL规
针对目前url 使用不规，提出以下建议。
一般域名后面建议就三层： https://域名/业务模块名/功能点/功能操作（？或/）
可选容
https://api.skyworthdigitailiotcom/业务模块名/功能点/功能操作
https://admin.skyworthdigitailiotcom/业务模块名/功能点/功能操作
注意事项：
采用子域名区分请amdin或app的, 不同子域名采用不同ip， 入口隔离。
url 字符串中不区分amdin或app， 但目前的header可以区分不同业务端，
同时可用于控制访问权限。
controller代码中，admin/app放到不同的controller文件中。但
RequestMapping不用区分是admin，还是app的功能。
4.2.2 REST
要遵循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.1 HTTPs
HTTPs 可以保障数据的性、完整性、身份校验安全性，所以应该实施全站HTTPs
化。 随着HTTP-2、HTTP-3技术的出现HTTPs的传输效率也有了极大的提
高。
4.3.2 OAuth2
是开放授权的一个标准，旨在让用户允许第三方应用去访问改用户在某服务器中
的特定私有资源，而可以不提供其在某服务器的账号密码给到第三方应用
4.3.3 JWT
JWT提供了一种用于发布接入令牌（Access Token),并对发布的签名接入令牌
进行验证的方法。 令牌（Token）本身包含了一系列声明，应用程序可以根据
这些声明限制用户对资源的访问。
4.3.4 OpenID Connect
它在OAuth2上构建了一个身份层，是一个基于OAuth2协议的身份认证标准
协议。OpenID Connect是OAuth 2.0协议之上的简单身份层，用 API 进行
身份交互的框架，允许客户端根据授权服务器的认证结果最终确认用户的身份，
以及获取基本的用户信息；它支持包括Web、移动、JavaScript在的所有客户
端类型；它是可扩展的协议，允许你使用某些可选功能，如身份数据加密、
OpenID提供商发现、会话管理。
4.4 配置中心
一般来说，测试环境的程序和正式环境的一个重要的差别，是配置不同。所以运
维相关的配置、程序参数外置，也符合无状态服务的理念， 做到测试环境、正
式环境一个部署包。
所以程序配置，应该存放在配置中心集中管理。
4.5 服务注册中心
注册中心最本质的功能可以看成是一个Query函数 Si = F(service-name)，以
Service-Name 为查询参数，Service-Name 对应的服务的可用的 Endpoints
(ip:port) 列表为返回值。
注册中心机制解耦了服务的提供者和服务的使用者，是微服务的关键设计模式。
4.6 API GateWay
API 网关对外采用门面设计模式，实现上采用责任链设计模式，是微服务的关
键设计模式。
4.7 服务通讯
推荐采用Http Rest & JSON方式做服务间通讯，简单也易于调试。随着
HTTP3.0基于UDP协议的使用，传输效率也会更好。
4.8 流量控制
微服务中由于模块较多，网络中因某些原因，有时会出现流量热点，甚于出
现拖垮整个集群的可能。我们不能束手无策，所以微服务集群流量控制上非
常必要。目前流量控制推荐使用Alibaba Sentinel， 它支持丰富的应用场
景、完备的实时监控、广泛的开源生态，可以很方便大家接入。
4.9 链路跟踪
当业务模块间调用关系比较复杂时，应引入链路跟踪功能。
5 Base Project项目
在微服务的实践中，我们不需要从头构建去构建一个微服务的体系， 所以选择
一个合适的BaseProject项目， 会使大家对微服务使用有一个良好的开端，有
利代码风格的统一、有一个较高的起点、以利于微服务的实施。
推荐大家使用Bladex项目，基于该项目完成微服务化实施。
6 部署和运维
6.1 程序Kubernetes化
Kubernetes和Docker，它是现代微服务设施的主力。推荐生产环境采用
kubernetes部署微服务。
6.2 数据库Kubernetes化
如果是公有云，数据库一般建议采用公有云RDS、如果是私有云一般数据库部
署外置于Kubernetes。 目前MySQL等数据库上Kubernetes, 还不是主流方
案。