微服务架构技术规范-第一版V2.2
微服务平台功能技术规范
微服务平台功能技术规范目录1适用范围 (5)2规范性引用文件 (5)3术语定义 (5)4总体功能要求 (6)4.1系统门户 (6)4.1.1服务订阅者视图 (6)4.1.2系统管理视图 (6)4.1.3租户运营运维视图 (6)4.2API网关 (6)4.2.1服务开放发布 (7)4.2.2API订阅管理 (7)4.2.3路由配置及管理 (7)4.2.4鉴权 (8)4.2.5服务过滤 (8)4.2.6编排 (8)4.3服务部署及管理 (9)4.3.1服务注册与发现 (9)4.3.2服务部署/升级/回退 (9)4.3.3服务版本管理 (10)4.3.4服务编排/依赖管理 (10)4.3.5服务目录 (10)4.3.6服务定义和SLA (11)4.3.7灰度发布 (11)4.3.8服务配置管理 (12)4.4服务核心能力 (12)4.4.1容错/熔断 (12)4.4.2服务隔离与迁移 (13)4.4.4负载均衡 (13)4.4.5安全访问控制 (14)4.4.6※通信框架 (14)4.4.7一致性 (14)4.5服务监控及治理 (15)4.5.1告警管理 (15)4.5.2资源监控 (15)4.5.3日志管理 (15)4.5.4性能监控 (16)4.5.5服务生命周期管理 (16)4.5.6服务调用链分析 (16)4.5.7安全管理 (17)4.5.8备份及容灾 (18)5总体技术要求 (19)5.1系统设计要求 (19)5.2系统设计指标 (19)5.3系统质量要求 (21)5.3.1功能完备性 (21)5.3.2开放性和扩展性 (21)5.3.3高可靠性 (22)5.3.4安全性 (23)5.3.5可监控性 (23)5.3.6鲁棒性 (23)5.3.7匹配性 (23)5.3.8兼容性 (24)5.3.9灵活性 (24)5.3.10准确性 (24)5.3.11易用性 (24)1适用范围2规范性引用文件下列标准所包含的条文，通过在本标准中引用而构成为本标准的条文。
.NetCore微服务架构
.NetCore微服务架构⼀、前⾔⼤家⼀直都在谈论微服务架构，园⼦⾥⾯也有很多关于微服务的⽂章，前⼏天也有⼀些园⼦的朋友问我微服务架构的⼀些技术，我这⾥就整理了微服务架构的技术栈路线图，这⾥就分享出来和⼤家⼀起探讨学习，同时让新⼿对微服务相关技术有⼀个更深⼊的了解。
⼆、技术栈2.1 ⼯欲善其事，必先利其器现在互联⽹盛⾏的年代，互联⽹产品也层出不穷，受欢迎的互联⽹产品都有⼀个⽐较⽜的技术团队，我这⾥分享下.net 微服务架构技术栈图如下：俗话说得好：⼯欲善其事，必先利其器。
⼀个优秀的⼯程师应该善于使⽤框架和⼯具，在微服务这⼀块的技术选型并⾮⼀蹴⽽就，需要经过⽇积⽉累和落地的项⽬才能完善。
下⽂我会⼀⼀分享技术栈中的主要框架和⼯具的使⽤场景，这篇⽂章就不⼀⼀分享实战例⼦。
2.2 微服务微服务如何“微”？微服务，当然核⼼是主题是“微”，怎么微呢？应该如何微呢？在我刚来杭州的时候接触过⼀个电商系统的单体架构，系统⽐较庞⼤，结合了各种电商该拥有的业务逻辑和场景，代码也⽐较难于维护，前前后后接⼿的⼈也⽐较多，代码耦合度太⾼，改个业务逻辑基本上是牵⼀发⽽动全⾝，跟我上个⽉分享的关于的⽂章中的电商系统最初的架构图类似，如下：那针对这个架构就有可“微”之谈了。
这⾥针对该单体架构可以做如下⼏个原则上进⾏“微”服务:根据业务来进⾏拆分，⼀个业务⼀个服务原则进⾏拆分，做到通⽤性业务服务模块，这样业务之间可以做到⾼内聚低耦合。
后⾯随意改动哪⼀块业务，只需要去改动这⼀块的业务微服务即可，其他业务不会受到影响。
⼀个业务模块⼀个独⽴的数据库为原则，相互平⾏的业务做到不需要相互依赖调⽤。
外层API⽹关进⾏业务逻辑的整合。
⼀个业务数据库⼀个微服务为原则。
结合分布式服务，可以快速版本迭代，发布平滑发布，不受时间影响，每时每刻都可以发布，⽆需半夜等到12点进⾏发布。
（⽐较痛苦的发布，犹如三⽇凌空般（有点夸张），曾经有段时间是每周都有那么⼏个晚上痛苦的发布，⼀发布就可能是凌晨4，5点，很多时候发布完，还要经过各种测试，最后发现问题还得线上改bug，我们回去的时候别的同事已经来上班了；当时我们的技术⼤佬说过这么⼀句话：“他连续⼀周都没看到过他的⼉⼦，回去的时候，他⼉⼦早就睡着了，起来上班的时候，他⼉⼦已经去学校了”，⼤家⼀定也有过这样的发布经历。
微服务框架的设计与实现
微服务框架的设计与实现①张晶1, 黄小锋2, 李春阳31(北京中电普华信息技术有限公司, 北京100192)2(中国电建集团国际工程有限公司, 北京100048)3(国网信息通信产业集团有限公司, 北京100031)摘 要: 相对于传统单块架构, 微服务框架具有技术选型灵活, 独立部署, 按需独立扩展等优点, 更适合当前互联网时代需求. 但微服务架构的使用引入了新的问题, 如服务注册发现、服务容错等. 对微服务框架引入的问题进行分析, 并给出了微服务框架的一种实现方案, 在框架层面解决服务注册发现、服务容错等共性问题, 使业务系统开发人员专注于业务逻辑实现, 简化系统开发的难度, 提高开发效率.关键词: 微服务框架; 服务注册; 服务发现; 服务容错Design and Implementation of Microservice ArchitectureZHANG Jing1, HUANG Xiao-Feng2, LI Chun-Yang31(Beijing China Power Information Technology Co. Ltd., Beijing 100192, China)2(PowerChina International Group Limited, Beijing 100048, China)3(State Grid Information & Telecommunication Industry Group Co. Ltd., Beijing 100031, China)Abstract: Compared with traditional single block architecture, microservice architecture has many advantages, such as flexible technology selection, independent deployment, and independent scalability more suitability for the current needs of the internet age, etc. But microservice architecture also introduces new problems such as service registration, service discovery, service fault tolerance. On the basis of the analysis for problems mentioned above, this paper proposes one implementation of microservice framework, which can solve service registration, service discovery, service fault tolerance and other common problems. Based on this, developers only need to focus on the development of business functions, so that it can simplify the difficulty of system development and improve development effectiveness.Key words: microservice architecture; service registration; service discover; fault tolerance传统信息化系统的典型架构是单块架构(Monolithic Architecture), 即将应用程序的所有功能都打包成一个应用, 每个应用是最小的交付和部署单元, 应用部署后运行在同一进程中. 单块架构应用具有IDE友好、易于测试和部署等优势, 但是, 随着互联网的迅速发展, 单块架构临着越来越多的挑战, 主要表现在维护成本高、持续交付周期长、可伸缩性差等方面[1].微服务架构(Microservices)的出现以及在国内外的成功应用, 成为系统架构的一种新选择. 很多大型宝等都已经从传统单块架构迁移到微服务架构[2]. 微服务架构提倡将单块架构的应用划分成一组小的服务, 互联网公司如Twitter、Netflix、Amazon 、eBay、淘服务之间互相协调、互相配合, 为用户提供最终价值.1 微服务架构微服务架构是一种架构模式, 采用一组服务的方式来构建一个应用, 服务独立部署在不同的进程中, 不同服务通过一些轻量级交互机制来通信, 例如RPC、HTTP等, 服务可独立扩展伸缩, 每个服务定义了明确的边界, 不同的服务甚至可以采用不同的编程语言来实现, 由独立的团队来维护[3].相对于传统的单体应用架构, 微服务架构具有单个服务易于开发、理解和维护; 复杂度可控; 技术选①收稿时间:2016-09-18;收到修改稿时间:2016-11-03 [doi: 10.15888/ki.csa.005796]型灵活; 独立部署; 按需独立扩展等优点[4]. 但是, 采用微服务架构也会引入新的问题, 本文对微服务架构引入的问题进行分析, 提出了一种微服务框架的实现方式, 在框架层面解决服务注册发现、服务容错等共性问题, 使业务系统开发人员专注于业务逻辑实现, 降低开发难度, 提升开发效率.1.1 微服务框架目前, 业界流行的微服务框架主要有两个: Spring Boot和Dropwizard. SpringBoot继承了原有Spring框架的优秀基因, 简化了开发、配置、部署和监控过程, 帮助开发者快速启动一个Web容器. Dropwizard 从前端网页、核心服务、资料库存取到资源监控, 提供了一个轻量级的开发架构, 帮助开发者快速的打造一个Rest风格的后台服务, 同时集成hibernate4、log4j、slf4j、jackson等开源组件.2 微服务框架设计基于微服务架构的应用是分布式系统, 增加了系统设计和实现的难度, 主要体现在以下几个方面:①在运行环境中, 微服务实例的网络地址是动态分配的, 微服务运行的实例数量也是动态变化的, 因此, 需要一套服务发现机制, 使服务调用者可以获取正确的服务地址, 同时服务提供者一般以集群方式提供服务, 也引入了负载均衡和健康检查问题.②在微服务架构中, 服务之间存在着复杂的依赖关系, 在高并发访问下, 依赖的稳定性影响系统的可用性及性能. 因此需要提供服务容错机制, 当依赖的服务发送故障时, 不会使调用方线程被长时间占用不释放, 避免故障在系统中蔓延.③每个服务独立部署运行, 服务之间的通信是进程间通信, 需要有一个高效的进程间通信机制支撑微服务之间的交互.④每个微服务可以有多个不同的实例, 这使得服务按需动态伸缩成为可能, 在高并发时可以启动同一服务的多个实例, 以提高响应速度. 但服务实例的启停及流量的调度和分发需要一套负载监控和负载均衡组件来管理.⑤一个微服务应用可能由上百个服务构成, 服务可以采用不同语言和框架. 每个服务都有自己的部署、资源、扩展和监控需求. 因此需要提供版本管理和部署组件, 实现微服务的动态部署和无缝升级. 2.1 服务发现目前服务发现的方式主要有两种: 服务端发现(server-side discovery)和客户端发现(client-side discovery). 这两种方式都通过注册中心方式提供服务注册信息的分布式管理. 当服务上线时, 服务提供者将服务信息注册到注册中心, 并通过心跳维持长链接. 服务调用者通过注册中心寻址, 根据负载均衡算法找到服务. 当服务下线时, 注册中心会发通知给服务客户端. 如图1和图2所示.图1 服务端发现图2 客户端发现服务端方式, 所有服务对于服务调用者透明, 但系统中需要维护一个高可用的负载均衡组件, 负载均衡组件在服务调用者和服务提供者之间增加了一跳, 有一定性能开销. 客户端方式架构简单, 扩展灵活, 同时服务消费方和服务提供方之间是直接调用, 没有额外开销, 性能比较好.2.2 服务容错在微服务架构中, 服务之间会有错综复杂的依赖关系. 在实际生产环境中, 由于网络连接缓慢、资源繁忙、脱机等原因会造成服务出错或者服务延迟, 如果微服务不能对其依赖的服务的故障进行容错和隔离, 那么该服务本身就处在被拖垮的风险中. 因此在微服务框架设计时需要加入容错措施, 确保某一服务出问题不会影响系统整体可用性. 可用的措施包括[5]:①断路器当某个微服务发生故障后, 通过断路器的故障监控, 向调用方返回一个错误响应, 调用方主动熔断, 以防止线程因调用故障服务被长时间占用不释放, 避免了故障在分布式系统中的蔓延. 如果故障恢复, 电路又能自动恢复.②限流增加限流机制, 限定对微服务的并发访问, 如限制单位时间内的并发数, 对超过这个限制的请求拒绝, 防止在突发流量或被攻击时被击垮.③回退回退是系统的弹性恢复能力, 是指在熔断或者限流发生的时候, 系统采用何种处理逻辑. 常见的处理策略有直接抛出异常, 也称快速失败; 返回空值或缺省值; 返回备份数据.2.3 总体架构通过对微服务框架进行分析, 确定了微服务框架的总体架构, 在框架层面解决负载均衡、服务发现、服务容错、监控报警、进程通信、自动化弹性部署等问题. 架构图如图3所示.图3总体架构图微服务框架包括基础开发框架、服务运行管理和部署监控工具三部分.基础开发框架: 提供微服务开发的基础组件, 包括展现组件、IOC组件、持久化组件、序列化组件、服务通信组件、服务监控组件、日志管理组件、缓存组件、嵌入式组件和权限管理组件, 实现微服务开发的通用功能, 整合开源成熟框架, 屏蔽底层技术细节. 其中, 日志管理记录重要的框架层日志、度量和调用链数据, 同时将日志、度量等接口暴露出来, 让业务层能根据需要记录业务日志数据; 服务通信组件提供基于REST/RPC的同步请求响应模式和基于消息的异步通信模式.服务运行管理: 提供微服务运行时服务注册、服务发现、服务路由及限流容错功能. 其中, 服务路由实现请求验证、请求动态路由和静态响应处理等功能; 限流和容错组件, 能够在运行时自动限流和容错, 保护服务. 同时和动态配置相结合, 实现动态限流和熔断.部署监控工具包括动态配置、部署管理、中间件监控、服务监控、调用链分析功能. 其中, 动态配置组件支持文件方式配置, 集成动态运行时配置, 能够在运行时针对不同环境动态调整服务的参数和配置; 部署管理实现一键部署灰度发布功能.3 框架实现3.1 技术架构微服务框架实现时采用的技术架构如图4所示.图4技术架构图在微服务框架实现时, 选择了业界开源成熟的框架, 通过框架整合实现微服务开发和运行管理. 其中Spring Boot作为微服务的基础开发框架, 提供展现、依赖注入、持久化、嵌入式容器、日志、缓存等基础功能. 集成Consul组件实现服务注册发现[6]; Ribbon 组件实现客户端负载均衡; Hystrix组件实现服务延迟和容错[7]; Zuul组件提供动态路由, 监控, 弹性, 安全等边缘服务.3.2 基础架构选型目前开源的微服务基础框架主要有Dropwizard和SpringBoot. 两个框架在实现技术上存在一定差异[8], 如表1所示.Dropwizard简单轻量, 但第三方集成力度不足, 社区支持薄弱, 很多关键特性如依赖注入需要开发者自己实现; Spring boot聚焦于Spring应用, 可以借力Spring家族体系的其它成员, 完成通信、数据访问等功能, 体系强大, 社区活跃. Spring Boot带来了一系列的生态圈的集成, 为微服务开发提供了基础. 因此选择Spring Boot作为基础框架.表1 Dropwizard和SpringBoot对比框架HTTP REST JSON Official integration Service typeSpring Boot TomcatJettySpringJacksonGSONJson-simple40+ OfficialStarter POMs forany purposeHTTP/RESTJMSMessageQueuingSOAPDropwizard Jetty Jersey JacksonHibernateValidator、Guava、ApacheHttpClient、Jersey、JDBI、Freemarker、Jodatime、MustacheHTTP/REST3.3运行管理框架服务运行管理引入了四个主流的开源框架, 每个框架相互独立, 实现时需要与基础框架Spring Boot集成. 为了实现框架整合, 同时简化开发难度, 引入Spring Cloud组件. Spring Cloud是一个基于Spring Boot实现的云应用开发工具, 它为基于JVM的云应用开发中的配置管理、服务发现、断路器、智能路由、分布式会话和集群状态管理等操作提供了一种简单的开发方式[9]. 以Hystrix组件整合为例, Spring Cloud提供了spring-cloud-starter-hystrix模块, 通过注解的方式轻松使用Hystrix, 如注解@HystrixCommand将断路器机制加入到业务处理方法中, 代码如表2所示.表2 @HystrixCommand示例.指定getProducerFallback为备用方法. 当断路器处于断开状态时, getProducerFallback方法将替代getValue接受调用.@HystrixCommand(fallbackMethod = "getProducerFallback")public ProducerResponse getValue() {return restTemplate.getForObject("http:.producer",ProducerResponse.class);}private ProducerResponse getProducerFallback() {return new ProducerResponse(42);}4 结语微服务框架已经在国家电网统一应用开发平台V2.9.0版本中实现, 该版本经过第三方安全、性能测试, 目前正在项目组试点应用.本文针对目前流行的微服务框架进行了介绍, 对微服务框架实现时需要解决的问题进行了分析, 设计了微服务的总体架构、实现架构, 重点分析了微服务架构所带来的服务注册发现、服务容错问题. 该微服务架构全面的解决了微服务开发的通用问题, 基于该微服务框架进行业务系统开发, 开发人员只需要关注微服务内部业务功能的开发, 可以降低系统的开发难度, 提高开发效率.参考文献1 王磊.解析微服务架构(一)单块架构系统以及其面临的挑战./cn/articles/analysis-the-architecture -of-microservice-part-01.[2015-05-11].2 姜斌.2016技术将继续颠覆现实发力引擎之“微服务”./article/a/2016-05-11/15838064.[201 6-05-11].3 Fowler M, Lewis J. Microservices. / articles/microservices.html.[2014-03-25].4 肖勤.微服务架构实践经验分享.http:/article/ 2015-08-07/2825412.[2015-08-12].5 杨波.实施微服务,我们需要哪些基础框架？http://www. /cn/articles/basis-frameworkto-implement-micro-se rvice/.[2015-12-01].6 HashiCorp. Introduction to Consul. https://www.consul. io/intro/index.html.7 Netflix. Hystrix: Latency and Fault Tolerance for Distributed Systems. https:///Netflix/Hystrix.8 Ullah R. Dropwizard vs Spring Boot—A Comparison Matrix. https:///articles/dropwizard-vs-spring-boot?utm_so urce=tuicool&utm_medium=referral.[2015-02-02].9 Pivotal Software. Spring Cloud. http://projects.spring.io/ spring-cloud/.2016.。
微服务规范
微服务规范概念和定义 (3)组件与服务 (3)去中心化和集中架构 (4)围绕业务功能进行组织 (5)产品不是项目? (5)强化终端及弱化通道 (5)分散治理 (5)分散数据管理 (6)基础设施自动化 (6)容错性设计 (6)设计改进 (6)其它 (7)微服务与SOA (7)多语言，多选择 (7)实践标准和强制标准 (7)原则 (8)Availability：标准的目标 (8)Production-Readiness标准 (8)Stability (8)Reliability (8)Scalability (9)FaultTolerance (9)Catastrophepreparedness (9)Performance (9)Monitoring (10)Documentation (10)服务化架构的演进历史 (10)历史 (10)MVC (10)RPC (10)SOA (11)微服务架构 (11)微服务架构的开发原则 (12)微服务架构的测试原则 (12)微服务架构的部署原则 (13)微服务架构的治理原则 (13)微服务的接口原则 (14)特征 (14)服务的业务要素必须唯一并不具有歧义 (14)服务必须在空间和时间上具有唯一性和稳定性 (14)服务需要具备多态性 (15)实践 (15)微服务的粒度 (15)微服务系统多大？ (15)微服务规划与设计 (15)人员角色的变化 (16)挑战 (16)问题 (17)“轻量化”解决方案 (17)安全性问题 (17)系统间耦合问题 (18)系统可靠性问题 (18)全局事务一致性问题 (18)异构系统问题 (19)组织需求与架构选择 (19)微服务是未来吗？ (20)附录 (20)关于微服务概念和定义简单来说，服务的本质就是行为（业务活动）的抽象。
对于SOA，推进结构化信息标准组织（OASIS）和开放团体（OpenGroup）均给出了正式定义。
OASIS将SOA定义为：Aparadigmfororganizingandutilizingdistributedcapabilitiesthatmaybeunderthecon trolofdifferentownershipdomains.Itprovidesauniformmeanstooffer,discover,inter actwithandusecapabilitiestoproducedesiredeffectsconsistentwithmeasurablepreco nditionsandexpectations.OpenGroup将SOA定义为：Service-OrientedArchitecture(SOA)isanarchitecturalstylethatsupportsservice-or ientation.Service-orientationisawayofthinkingintermsofservicesandservice-base ddevelopmentandtheoutcomesofservices.Aservice:Isalogicalrepresentationofarepeatablebusinessactivitythat●hasaspecifiedoutcome(e.g.,checkcustomercredit,provideweatherdata,consolidatedrillingreports)●Isself-containedMaybecomposedofotherservices●Isa“blackbox”toconsumersoftheservice业界基本的认知是，SOA是一种架构模式，是一种面向服务的思维方式。
微服务架构技术手册
微服务架构技术手册第一章简介微服务架构是一种软件架构风格，将一个大型应用程序拆分为多个小而独立的服务，每个服务都可以独立部署和扩展。
本技术手册将为您介绍微服务架构的概念、原理、优势以及实施和管理微服务架构的技术要点。
第二章微服务的概念与原理2.1 微服务概念微服务是一种强调解耦、高内聚与独立部署的服务架构。
通过将应用程序拆分成多个服务，每个服务都可以独立开发、测试、部署和扩展，实现了系统内部的松耦合。
2.2 微服务架构特点微服务架构具有以下几个特点：（1）服务拆分：将大型应用拆分成多个小服务，每个服务专注于实现一个业务功能；（2）独立部署：每个服务都可以独立进行部署，开发人员可以快速迭代和发布新功能；（3）弹性扩展：根据实际需求，可以对某个服务进行水平或垂直扩展，提高系统的可伸缩性和性能；（4）自治性：每个服务都有自己的数据存储、业务逻辑和界面，可以独立开发和演进；（5）容错性：由于服务之间松耦合，当某个服务出现故障时，其他服务仍可以正常运行。
第三章微服务架构的优势3.1 弹性伸缩微服务架构允许根据需求对单个服务进行独立扩展，提高系统的弹性和可伸缩性。
通过动态添加或删除服务实例，能够快速适应负载的变化，提供更好的用户体验。
3.2 独立开发和部署由于每个微服务都是独立的，开发人员可以专注于某个具体的业务功能，快速进行开发、测试和部署。
这种模块化的开发方式大大提高了团队的协作效率。
3.3 技术多样性微服务架构允许每个服务使用不同的技术栈进行开发，选择最适合业务需求的技术工具。
这样，可以让每个团队选择自己熟悉和擅长的技术，提高开发效率和质量。
3.4 容错和隔离性微服务架构中，各个服务之间是相互独立的，一个服务的故障不会影响其他服务的运行。
这种容错和隔离性使得系统更加稳定可靠，降低了故障对整个系统的影响。
第四章实施微服务架构的关键技术4.1 服务拆分选择合适的服务拆分策略是实施微服务架构的关键。
可以根据业务功能、领域边界或数据模型等因素进行服务拆分，确保拆分后的服务具有独立部署和扩展的能力。
微服务架构及技术路线
微服务架构及技术路线微服务架构是一种将复杂的大型应用程序划分为一系列小型、独立部署的服务的架构风格。
每个服务都有自己独立的业务功能，并通过轻量级通信机制进行相互通信和协同工作。
微服务架构的核心理念是通过将应用程序划分为一系列自治的服务，以提升应用程序的可伸缩性、可部署性和可维护性。
微服务架构的设计原则包括单一职责原则、自治性原则、可替代性原则、独立性原则、最终一致性原则等。
通过将系统拆分为小型服务，可以实现更加灵活和可扩展的开发、测试、发布和维护流程。
每个微服务可以单独开发、测试和部署，同时可以使用不同的技术栈和开发语言。
这样的设计可以减少代码耦合、提高开发效率和系统的弹性。
在微服务架构中，通信和协作是非常重要的。
常用的通信方式包括RESTful API、消息队列、事件驱动等。
为了确保不同服务之间的协作，可以使用服务注册与发现机制，如Consul、Eureka等。
此外，为了提高系统的可靠性、可伸缩性和可监控性，还可以使用负载均衡、容器化部署、监控和日志收集等技术。
1.服务拆分与设计拆分大型应用程序为小型的自治服务是微服务架构的核心。
在进行服务拆分时，可以遵循领域驱动设计（DDD）等原则，将业务划分为不同的领域和子域，每个子域对应一个微服务。
同时，还需考虑服务之间的依赖关系和通信方式，以确保服务之间的松耦合。
2.服务开发和测试每个微服务都可以使用不同的技术栈和开发语言。
在开发服务时，可以选择适合具体需求的编程语言和框架。
同时，需要为每个服务编写单元测试、集成测试和端到端测试，以保证服务的质量和可靠性。
3.服务部署和容器化4.服务通信与协作微服务之间的通信和协作是非常重要的。
可以使用RESTful API、消息队列等方式进行服务间的通信和数据交换。
同时，还需考虑服务注册与发现、负载均衡等机制，以确保服务的可用性和可靠性。
5.监控和日志收集6.持续集成和持续部署总之，微服务架构是一种灵活、可扩展和可维护的架构风格。
微服务架构介绍
微服务架构介绍1微服务架构介绍微服务架构(MicroserviceArchitect)是近年来软件开发领域兴起的一种新型软件架构，是一项在云中部署应用和服务的新技术。
它提倡将单块架构的应用划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。
每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。
微服务架构旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。
2微服务架构的优缺点2.1.优点（1）微服务将巨大单体式应用分解为多个小服务，每个服务业务清晰、功能明确简单、代码量小，开发和维护单个微服务相对简单。
解决了系统开发和维护的复杂性问题。
（2）每个微服务可以有不同的人员进行开发，并且开发技术栈不受限制，开发人员可以采取不同的技术进行开发。
（3）每个微服务可以独立的部署，相对于单体应用来说，微服务架构下若某一功能需求发生变更，只需对这一单独的服务重新编码部署，不影响其他服务的使用。
（4）每个服务独立扩展，可以根据新的需求，实现细粒度的扩展。
2.2.缺点（1）效率低：开发都在同一个项目改代码，相互等待，冲突不断；（2）维护难：代码功功能耦合在一起，新人不知道何从下手；（3）不灵活：构建时间长，任何小修改都要重构整个项目，耗时（4）稳定性差：一个微小的问题，都可能导致整个应用挂掉；（5）扩展性不够：无法满足高并发下的业务需求；3SpringCloud微服务框架SpringCloud是一个微服务框架，主要为了简化分布式系统的开发。
利用SpringBoot一键启动、部署的特点对云应用开发中的服务注册发现、APIGateway、断路器、服务配置治理、负载均衡等操作都提供了简单的开发方式。
由于SpringCloud微服务框架相对于其他微服务框架更为成熟，Spring社区也更为活跃，故市面上大多选用SpringCloud 作为系统微服务的开发框架。
图解微服务技术架构体系
图解微服务技术架构体系▪Hello，Microserviceso什么是微服务o微服务的利与弊o什么组织适合使用微服务？▪微服务技术架构体系o服务发现o网关o配置中心o通讯方式o监控预警o熔断、隔离、限流、降级o容器与服务编排引擎o下文，你将看到业界主流微服务框架的核心原理，包括服务发现，网关，配置中心，监控等组件，功能和架构原理的简单介绍。
感谢阅读！什么是微服务微服务Microservices之父，马丁.福勒，对微服务大概的概述如下：就目前而言，对于微服务业界并没有一个统一的、标准的定义（While there is noprecise definition of this architecturalstyle ) 。
但通在其常而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。
服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP 的 RESTful API ) 。
每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。
另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。
可以使用不同的语言来编写服务，也可以使用不同的数据存储。
根据马丁.福勒的描述，我总结了一下几点：康威定律（字差，勿嫌）小服务小服务，没有特定的标准或者规范，但他在总体规范上一定是小的。
进程独立每一组服务都是独立运行的，可能我这个服务运行在tomcat容器，而另一个服务运行在jetty上。
可以通过进程方式，不断的横向扩展整个服务。
通信过去的协议都是很重的，就像ESB，就像SOAP，轻通信，着意味着相比过去更智能更轻量的服务相互调用，就所谓smart endpoints and dumb pipes，这些endpoint都是解耦的，完成一个业务通信调用串起这些micro service就像是linux系统中通过管道串起一系列命令业务。
微服务开发标准
微服务开发标准一、架构设计1.1单一职责原则每个微服务应只负责其特定的业务功能，避免功能冗余。
1.2分布式系统设计采用分布式系统设计，以提高系统的可扩展性和可维护性。
1.3接口设计采用RESTfulAPI设计，以确保不同微服务之间的通信标准化和简洁化。
二、开发规范2.1代码规范遵循统一的代码规范，包括命名规范、缩进、注释等。
2.2开发语言使用主流编程语言，如Java、Python、Go等。
2.3开发工具使用主流的开发工具，如Git、Docker、Maven等。
三、测试标准3.1单元测试对每个微服务进行单元测试，确保每个功能模块的正确性。
3.2集成测试对微服务之间的接口进行集成测试，确保接口的稳定性和可靠性。
3.3性能测试对微服务进行性能测试，确保在高负载情况下系统的稳定性。
四、部署流程4.1持续集成与持续部署（CI/CD）采用CI/CD流程，实现代码提交后自动构建、测试和部署。
4.2版本控制使用版本控制工具，如Git，对代码进行版本控制。
4.3容器化部署使用容器化技术，如Docker，实现快速部署和容器编排。
五、监控与日志5.1监控系统建立监控系统，对系统的性能、可用性等进行实时监控。
5.2日志系统建立日志系统，收集并分析日志数据，以帮助排查问题及优化系统性能。
六、安全与认证6.1安全策略制定并执行统一的安全策略，包括数据加密、访问控制等。
6.2认证与授权实现统一的认证与授权机制，以确保系统的安全性。
七、扩展性与容错7.1扩展性设计设计可扩展的系统架构，以满足业务增长的需要。
7.2容错机制实现系统的容错机制，以防止因单点故障导致的系统瘫痪。
八、性能优化8.1代码优化针对代码级别进行优化，包括算法优化、减少不必要的计算等。
8.2系统配置优化对系统配置进行优化，包括调整数据库连接池、缓存设置等。
8.3使用性能分析工具使用性能分析工具，如Profiler，对系统性能进行深入分析，找出性能瓶颈并进行优化。
微服务架构技术分享
5
单体应用
优点： • 开发简单，IDE支持友好 • 部署容易，一个WAR包搞定 • 简单可伸缩，可通过负载均衡器运行多个副本 • 技术栈单一，开发门槛低 • 事务控制简单，由框架完成
缺点： • 代码庞大，关系错综复杂 • 编译时间长，持续集成困难 • 部署臃肿，需重启容器，可插拔性差 • 功能代码间互相影响 • 扩展能力受限，新技术与工具框架使用受限 • 所有服务在一个进程内
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务， 服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独 立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能 够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、 集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择 合适的语言、工具对其进行构建。
物务理上的解耦 • 每需个设服计务服可务使间用的不通同信语机言制，，不进同行架复构杂，的
不分同布技式术的开事发务（控只制要。接口不变），系统 • 不数会据长库期进被行限物制理在上一的个分技库术分栈表上，，每且个每数
个据服服务务所维承护载着硬独件立资的源数可据以逻不辑同，不同域 • 容的错库性表高间，无一法个jo服in务的内存泄漏，并不 • 会服导务致追整踪个，系日统志的管奔理溃，自动化部署，服
6
微服务架构诞生背景
它是互联网高速发展，敏捷、精益、持续 交付方法论的深入人心，虚拟化技术与
DevOps文化的快速发展以及传统单块架构
无法适应快速变化等多重因素的推动下所 诞生的产物：
1
互联网行业的快速发展，在需求变化快、用户量庞大的 情况下，如何保证系统的可伸缩性、高可用性成为系统
微服务接口定义规范标准[详]
![微服务接口定义规范标准[详]](https://img.taocdn.com/s3/m/b1666cf5f80f76c66137ee06eff9aef8941e48e8.png)
接口定义规范研发部2018/011．URI命名规范32．使用方法表示动作行为43．使用内容协商处理资源表示内容44．使用响应状态码标识处理结果状态55．使用HAL<HypertextApplicationLanguage>作为响应数据格式6 6．各方法成功处理后的返回数据87．不要对返回结果进行封装88．支持资源的字段裁剪,减少响应中返回的字段数量99．使用 OAuth2 来确保API 的安全性910．确保GET,PUT,DELETE 请求是幂等的911．API版本9微服务接口设计采用Restful风格的接口规范,下面是基于Restful风格要求制订的接口设计规范。
1．URI命名规范➢不用大写；➢用中杠-不用下杠_；➢参数列表要encode；➢使用名词作为资源名称<例如,不要在网址中使用动词>；➢使用资源集合的概念；❖每种资源有两类URI〔接口：◆资源集合〔例如,/orders；◆集合中的单个资源〔例如,/orders/{orderId}。
❖使用复数形式<使用‘orders’而不是‘order’>；❖资源名称和ID 组合可以作为一个网址的节点；例如,/orders/{orderId}/items/{itemId}；❖尽可能的让网址越短越好,单个网址最好不超过三个节点。
可以使用查询参数代替路径中的节点组合➢对Composite资源的访问服务器端的组合实体必须在uri中通过父实体的id导航访问。
GET /orders/12/items➢使用有意义的资源描述；❖"禁止单纯的使用ID!" 响应信息中不应该存在单纯的ID,应使用链接或是引用的对象；❖设计资源的表述信息,而不是简简单单的做数据库表的映射；❖合并表述信息,不要通过两个ID 直接表示两个表的关系；➢资源的集合应支持过滤,排序和分页；过滤、排序、分页应出现在参数列表中而不是Path中。
例如：GET /currencies?page=1&size=10过滤条件应该合并到一个参数里：GET ://example/users?filter="name::todd|city::denver|title::grand poobah"排序字段也应该合并到一个参数里,使用-代表倒序GET ://example/users?sort=last_name|first_name|-hire_date ➢经常使用的、复杂的查询标签化,降低维护成本。
微服务开发技术详解及其架构设计
微服务开发技术详解及其架构设计随着互联网行业的发展和技术的不断更新，微服务架构逐渐成为一种主流的开发方式。
相比于传统的单体架构，微服务架构将系统划分为若干个小型服务，每个服务都可以独立开发、测试、发布和部署。
这种架构可以极大地提高开发效率和系统的可维护性，同时也能够更好地应对大规模系统的复杂性。
在微服务开发中，我们需要考虑的问题很多。
除了业务逻辑的实现之外，我们还需要考虑服务的注册与发现、负载均衡、服务监控、日志记录等方面的问题。
下面，我将一一介绍这些问题，并介绍一些常用的开发技术和工具。
1. 服务注册与发现在微服务架构中，服务的注册与发现十分重要。
服务注册可以让服务在启动时自动将自己的信息注册到注册中心上，而服务发现则可以让客户端自动发现服务并获取服务的地址。
目前常用的服务注册与发现工具有Consul、Eureka和Zookeeper等。
其中，Consul最新版新增了Service Mesh功能，提供了更加灵活和可靠的服务治理方案。
2. 负载均衡在微服务架构中，服务的负载均衡也是一个重要的问题。
负载均衡可以让请求平均分布到多个服务实例上，避免单一实例出现过载或响应缓慢的情况。
目前常用的负载均衡工具有Nginx、HAProxy和Zuul等。
此外，Service Mesh中的Istio也提供了负载均衡功能。
3. 服务监控服务监控是微服务开发中必不可少的一个环节。
通过监控系统，我们可以实时了解服务的健康状况、请求响应时间、错误率等指标。
目前常用的监控工具有Prometheus、Grafana和ELK等。
此外，Service Mesh中的Linkerd也提供了类似的监控功能。
4. 日志记录在微服务开发中，服务的日志记录也是一个很重要的环节。
通过日志记录，我们可以方便地追踪和排查问题。
目前常用的日志记录方案有ELK、Log4j和Logback等。
此外，Service Mesh中的Istio也提供了日志记录功能。
技术架构规范范文
技术架构规范范文一、引言二、技术架构原则1.单一职责原则：每个模块、每个组件都应该有清晰明确的职责，避免模块或组件的功能过于复杂。
2.高内聚低耦合原则：模块或组件之间应该尽可能地解耦合，减少相互依赖关系，提高系统的灵活性和可维护性。
3.可扩展性原则：系统设计应考虑未来的扩展需求，采用模块化和插件化的方式，方便对系统进行功能的扩展和修改。
4.系统安全性原则：系统应考虑各种安全威胁，采取防御措施，保证系统的机密性、完整性和可用性。
5.性能优化原则：系统设计应考虑性能优化，包括响应时间、并发性、吞吐量等方面的优化，提高系统的性能和用户体验。
三、技术架构设计1.架构层次结构：系统的技术架构应采用分层的结构，包括表现层、应用层、数据层等，各层之间通过明确的接口进行通信，便于分工协作和系统扩展。
2.技术选型和规范：对于各种技术的选型和使用应有明确的规范，包括编程语言、开发框架、数据库、中间件等，避免使用过时或不稳定的技术。
3.模块化设计：系统的各个模块应该采用模块化的设计，每个模块都有清晰的职责和接口，便于分工开发和维护。
4.异步处理和消息队列：对于大量的异步处理和并发请求，应考虑采用消息队列和异步处理的方式，提高系统的并发性和性能。
5.缓存和数据库设计：对于频繁读取的数据，应采用缓存的方式减少数据库的访问开销，提高系统的响应性能和吞吐量。
合理设计数据库结构和索引，避免数据库的性能瓶颈。
四、开发规范1.代码规范：对于编写的代码应符合一定的代码规范，包括命名规范、缩进规范、注释规范等，保证代码的可读性和可维护性。
2. 版本管理：对于代码的版本管理应采用专业的版本管理工具，如Git，确保代码的版本控制和团队协作的效率。
3.单元测试和集成测试：每个模块或组件都应编写相应的单元测试用例和集成测试用例，确保代码的质量和功能的正确性。
4.代码复用和组件化：对于常用的功能和组件应进行代码复用和组件化，提高开发效率和代码的可维护性。
微服务项目开发规范
微服务项目开发规范微服务是一种架构风格，通过将一个复杂的应用程序拆分成一系列更小、更易于开发和管理的服务来实现。
每个服务在一个独立的进程中运行，并通过轻量级机制（通常是HTTP资源API）进行通信。
微服务架构具有多个优点，包括增强的可伸缩性、可维护性和可测试性。
为了确保微服务项目的协调开发和良好的质量，制定一套规范是非常重要的。
以下是一些可以用于微服务项目开发的规范：1.项目目录结构规定项目目录结构能够帮助开发团队更好地理解项目结构和组件之间的关系。
可以使用一种标准的目录结构，如按照领域模型来组织代码。
例如，可以按照服务、领域对象、数据访问对象等来组织代码。
2.命名约定定义一套统一的命名约定能够提高代码的可读性和可维护性。
例如，类名使用驼峰命名法，方法名使用动词开头等。
此外，还可以使用一种标准的命名方式来命名微服务和API端点。
3.代码风格和规范统一的代码风格和规范有助于整个团队的协同开发。
可以选择一种常用的编码规范，如Google编码规范或阿里巴巴Java开发手册，并使用代码检查工具来强制执行这些规范。
4.版本控制5.API设计和规范约定API设计规范能够确保不同服务之间的接口一致性，并易于理解和使用。
可以使用一种标准的API设计规范，如RESTful API设计规范，并使用工具来检查和验证API的一致性。
6.测试策略制定一套统一的测试策略可以确保项目的稳定性和质量。
建议使用自动化测试框架来编写和运行单元测试、集成测试和端到端测试，并在每次代码变更时运行测试套件。
7.依赖管理使用一种依赖管理工具（如Maven或Gradle）来管理项目的依赖关系。
确保每个服务的依赖明确地声明在配置文件中，并使用工具来自动解析和更新依赖关系。
8.性能优化和监控为了确保微服务项目的高性能和稳定性，制定一套性能优化和监控规范非常重要。
可以使用一些常用的性能优化技术，如缓存、异步处理和并发控制，并使用性能监控工具来检测和解决性能问题。
半导体微服务架构 技术参数
半导体微服务架构技术参数1. 引言随着信息技术的快速发展，半导体行业的竞争也日益激烈。
为了提高产品的质量和效率，半导体企业开始采用微服务架构来构建其软件系统。
本文将详细介绍半导体微服务架构的技术参数，包括架构设计原则、通信协议、数据存储、安全性等方面。
2. 架构设计原则半导体微服务架构的设计原则是将复杂的系统拆分为多个小型的、独立的服务。
每个服务都专注于解决特定的业务需求，并通过轻量级的通信机制进行交互。
以下是一些常用的架构设计原则：•拆分：将系统拆分为多个微服务，每个微服务负责一个特定的业务功能，以实现高内聚低耦合的目标。
•自治性：每个微服务都是独立的，具有自己的数据存储和处理逻辑，可以独立部署和扩展。
•弹性：微服务架构可以根据负载情况进行自动扩展和收缩，以保证系统的高可用性和性能。
•可观察性：通过集中的日志、监控和告警系统，实时监控和分析微服务的运行状态。
3. 通信协议在半导体微服务架构中，各个微服务之间需要进行通信来实现业务需求的协调和数据的传递。
常用的通信协议包括：•HTTP/HTTPS：基于HTTP协议的RESTful API是微服务之间常用的通信方式，其简单、灵活且易于使用。
•RPC：远程过程调用（RPC）是一种高性能的通信方式，可以实现微服务之间的直接调用，提高系统的性能和效率。
•消息队列：通过消息队列实现微服务之间的异步通信，可以提高系统的可靠性和弹性。
选择合适的通信协议需要根据具体的业务需求和性能要求进行评估，同时考虑到系统的可扩展性和易用性。
4. 数据存储半导体微服务架构中的数据存储需要满足高性能、高可用性和可扩展性的要求。
常用的数据存储技术包括：•关系型数据库：关系型数据库（如MySQL、Oracle）可以满足大部分的业务需求，但在面对大规模数据和高并发访问时性能有限。
•NoSQL数据库：NoSQL数据库（如MongoDB、Redis）具有高性能、可扩展和灵活的特点，适合处理大规模数据和高并发访问。
微服务架构技术规范-第一版V2.2
微服务架构技术规范-第一版V2.2-标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII微服务架构技术规范（试行稿）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)，就是没有实例变量的对象.不能保存数据，是不变类，是线程安全的。
微服务-框架
配置
除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，能够在运行时针对不同环境动态调整服务的参数和 配置
限流和容错
框架集成限流容错组件，能够在运行时自动限流和容错，保护服务，如果进一步和动态配置相结合，还可以实现动态限流 和熔断
服务框架-封装公共关注点
管理接口
框架集成管理接口，一方面可以在线查看框架和服务内部状态，同时还可以动态调整内部状态，对调试、监控和管理能提 供快速反馈。Spring Boot微框架的Actuator模块就是一个强大的管理接口
服务容错-最佳实践
舱壁隔离模式(Bulkhead Isolation Pattern)
该模式像舱壁一样对资源或失败单元进行隔离，如果一个船舱破了进水，只损失一个船 舱，其它船舱可以不受影响 。线程隔离(Thread Isolation)就是舱壁隔离模式的一个例子， 假定一个应用程序A调用了Svc1/Svc2/Svc3三个服务，且部署A的容器一共有120个工作线程， 采用线程隔离机制，可以给对Svc1/Svc2/Svc3的调用各分配40个线程，当Svc2慢了，给 Svc2分配的40个线程因慢而阻塞并最终耗尽，线程隔离可以保证给Svc1/Svc3分配的80个线 程可以不受影响，如果没有这种隔离机制，当Svc2慢的时候，120个工作线程会很快全部被 对Svc2的调用吃光，整个应用程序会全部慢下来。
分布式系统中的轻量级消息代理总线,用于在集群节点之间传播状态改变事件(配置改变等)；目前只用AMQP协议的实现;
用一个注解就可以实现OAuth2方式的权限认证、单点登录。可以通过Zuul代理传递单点登录信息到后端服务
开源框架-spring cloud
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
微服务架构技术规范（试行稿）
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.1URL规范
针对目前url 使用不规范，提出以下建议。
一般域名后面建议就三层：https://域名/业务模块名/功能点/功能操作（？或/）
可选内容
https://api.skyworthdigitailiotcom/业务模块名/功能点/功能操作
https://admin.skyworthdigitailiotcom/业务模块名/功能点/功能操作
注意事项：
采用子域名区分请求是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 2.0协议之上的简单身份层，用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方式做服务间通讯，简单也易于调试。
随着HTTP3.0基于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, 还不是主流方案。