给卖假性药的做网站一般要判多久,电子开发网站,给千图网等网站做设计赚钱吗,杭州模板建站定制网站原创#xff1a; 李宁 博云技术社区 导读 微服务已经成为过去几年软件架构设计的“事实标准”#xff0c;大多数企业在推动内部数字化转型的过程中#xff0c;服务软件系统开始由单一或者SOA服务向微服务转型。那么转型过程需要遵循哪些原则呢#xff1f;本文结合过往博云…
原创 李宁 博云技术社区 导读 微服务已经成为过去几年软件架构设计的“事实标准”大多数企业在推动内部数字化转型的过程中服务软件系统开始由单一或者SOA服务向微服务转型。那么转型过程需要遵循哪些原则呢本文结合过往博云微服务落地实践经验分享微服务落地实践的过程中思考。 目前当技术人员提及微服务的时候首先想到的是Spring Cloud、Dubbo等实现服务的技术框架。这在我们采用微服务的初期阶段是最先考虑的因素。可是随着服务化的进行我们并没有享受到由框架的便利性与快捷性所带来的业务突飞猛进的成就感。恰恰相反过多的服务化以及服务间冗余且多元化通信机制反而加重了业务处理的负担。这必然不是我们想要的微服务却是大多数企业在执行的微服务。 因此我们开始重新审视整个行业审视微服务的发展历程。与过往不同的是前期阶段我们把更多的精力投入到业务上而一定程度上“忽略”技术因为此时我们建立的信念是无论何种形式的“服务形态”一定是为业务服务的。 当我们站在全局的角度观看整理后的服务发现了一个极其优美的图形化结构各个节点的边界清晰职责分明节点间的链路畅通协议规整。这时我们知道我们终于走在了正确的道路上。 我们遵循的原则 当经过一定时间的挣扎以后我们觉得微服务的关注点不在于技术本身但并不意味着不关注技术。在反思过程中我们认为微服务实践中有两个原则不能变服务一定是围绕业务的服务的交互是标准的。我们把原则分为两个阶段初期阶段实践阶段。 初期阶段 初期阶段遵循第一条原则服务一定是围绕业务的。微服务初期阶段重要的是业务梳理而不是花费大量时间在RPC、Service Discovery、 Circuit Breaker这些概念或者EurekaDockerGatewayDubbo等技术框架的调研上此时我们重心关注服务的边界与职责划分。 这是遵循的两条原则1、保证单一业务服务高效聚合2、降低服务间的相互调用此举是避免陷入大量分布式业务的处理。这样的原则下DDD为我们提供了帮助也依据业务本身的特性实现了服务初期阶段的整理。同时我们发现就算借助DDD的指导在不同的业务应用中各个服务也有不同的聚合形态和调用方式。因此我们觉得微服务本身没有一成不变的模式一切都是围绕业务动态变化的。合理性也仅仅体现在一定阶段的时间范围之内。 实践阶段 当业务建模完成我们能够清晰的知道各个业务的职责以及与其他业务的关联关系从理论层面我们完成了业务微服务建模。此时我们开始着手服务的落地实践在落地实践阶段我们更多关注点同样不在于技术框架而是在于技术框架的内涵-即服务交互标准。 此时我们遵循了第二条原则服务的交互是标准的。所谓服务交互标准从三个层面解读协议标准框架标准接口标准。 协议标准
目前网络应用的协议比较复杂我们希望选取能够符合业务场景的协议作为通信标准。因此我们考虑了统一的认证鉴权协议、加密解密协议、内部接口交互协议外围接口服务协议等各个协议各司其职用来支撑服务通信的标准化。协议标准不仅仅为平台自身服务同时与其他业务单元进行通信时只需要遵循协议标准就可以实现业务单元之间的快速联动。 框架标准
为了支撑业务我们没有依赖任何的自动化代码生成框架而是根据我们的协议支持情况选择最小的服务运行框架来构建统一的业务单元支撑框架。这里需要说明的一点框架标准需要考虑业务特性协议特性不能一概而论因此它的有效性也许只在当前构建的业务平台本身。构建标准框架的好处是针对应用内的所有业务单元可以快速复制简化因为各自开发框架不同导致联调阶段出现问题。 接口标准
接口分两种业务内部接口和业务服务接口。无论哪种接口同样遵循标准化原则。 业务内部接口的核心在于压缩协议加快业务的处理流程因此可以采用RPC等高效率的协议支持的接口模式业务服务接口的核心在于表明业务携带的信息因此采用restful接口规范更合适一些。接口设计需要涵盖但不限于标准化的请求方式、统一的参数处理、统一的结果返回、统一的异常处理、统一的日志处理等。 服务拆分与聚合 前提服务拆分与聚合在本篇文章中暂时不考虑web的微服务化设计只说明后端服务的拆分与聚合实践。 服务拆分与聚合需要遵循的原则服务一定是围绕业务的。但事实情况是在现在追求“开源整合”的背景下纯粹的业务单元在不借助第三方工具的前提下需要消耗巨大的代价才能实现业务需求同时也出现不同业务单元对同一个工具的强依赖性。因此在服务拆分与聚合时我们考虑了两种形态的实现方式业务支撑与工具支撑。 业务支撑
业务支撑需要考虑的是业务服务对象和业务内部逻辑。业务服务对象作为整个业务单元的对外形态通过命名能够清晰的表达其涵盖的业务范围业务内部逻辑需要对业务单元进行细粒度的拆分类似一个实体类可以包括多个其他相关联的实体对象当然如果服务拆分的足够细化也可以把内部逻辑作为独立的业务单元但是这样会加重业务直接的通信负载。基于业务内部逻辑构建业务服务对象的真实场景。具体的拆分细节可以依赖DDD的实践方法进行当然也需要根据业务做相应调整没有普世之道。 工具支撑
工具支撑需要结合业务考虑分为两种通用性工具和专用性工具。通用性工具旨在为所有业务单元运行提供统一的支撑平台从而减少由于工具维护花费的精力使得业务开发人员聚焦业务实现一般通用工具包包括统一日志处理统一拦截处理返回数据统一封装异常统一处理等等专用性工具聚焦某个具体的业务单元由业务单元自身维护例如迭代升级。工具支撑层面不会提供对外restful或者rpc的接口对外的表现形式为编译好的依赖工具包例如Github的管理接口的封装。 服务架构选型 依照执行原则完成服务拆分以后我们需要考虑的是合适的落地选型。选型方案要考虑的因素有很多技术背景尤其是团队内编程语言的设定服务支撑工具注册中心网关服务调用负载均衡数据库等服务运行工具tomcatjettyjboss等服务部署工具物理部署虚拟化容器等工具的协议支撑集合httprpcmtqqidoc等。但是无论如何选型最终一定要结合团队开发人员当下的技能支撑这也是我们选型的核心因素因为白盒相对来说始终比黑盒安全也相对可控。 这里给出我们的技术栈选型框架仅限我们熟悉的内容暂时不涉及技术框架的对比说明。 服务开发框架springbootdubbogrpcServiceMesh基于ServiceMesh的开发服务框架
分布式存储/注册中心ZookeeperConsulEurekaEtcd
服务网关KongOpenrestySpring cloud ZuulSpring cloud gateway
负载均衡nginxspring cloud RibbonhaproxyKubernetes service
服务远程调用Spring cloud feign
缓存服务memchaceredis
数据库mariadbmysql
消息服务RabbitMQNATSKafka
配置中心spring cloud configApolloConsul
事件机制Cloud Event
服务编排Conductor Kubernetes
服务治理spring cloudDubboServiceMesh
基于消息机制的分布式事务处理遵循CAP或者BASE理论模型的实现
业务运行工具jvmnginx或者其他可运行环境支撑
开发编译工具Jenkinsmavengitlab
接口文档Swagger
部署工具物理部署jar包或者可运行的编译的二进制文件虚拟化部署虚拟镜像模板容器化部署Docker 我们在落地的过程中根据团队技术特点开发阶段重点选择了Spring Cloud中涵盖的技术栈。方便易用能够快速入手。运行阶段选择具备服务编排能力的Kubernetes容器化运行环境并且结合Devops工具链能够快速迭代部署。 服务接口设计 服务接口是对外展现业务逻辑的唯一入口接口定义的规范与否也是微服务落地的关键指标之一我们在实践的过程中参考了多个开源项目的接口设计针对任何一个资源对象整体分为几类场景资源集合类操作资源实体操作异常处理参数处理统一数据返回审计日志以及其他具体场景。 统一的接口请求与响应标准 其中业务单元绝大多数端口围绕着资源集合类、资源实体类进行操作因此我们从restful接口规范出发结合具体场景规范了请求方式请求url请求参数请求header响应header响应值等信息。 请求参数涵盖默认语义包括Get获取信息Post创建Put全量修改Patch部分修改Delete删除
以Students实体对象的新建为例给出请求与响应标准。 URL
URL请求包括三部分请求方式统一前缀以及具体url统一前缀具备一定含义的命名规则包括api申明供应商标识版本说明等必要信息例如 Post /api/cloud/v1/students?exist{skip,replace} 请求header
type aplication/json用于single和bulk时用来表示请求数据为json格式 application/vnd.ms-excel从excel格式的文件导入创建
Accept aplication/json接受json格式的响应数据
Authorization Oauth2.0的access tokenbearer token
Accept-Language可选 可接受的语言国际化en-US表示美国英语 请求数据格式类型
json格式{items:[]}
请求创建students对象json表达
请求批量创建student对象列表json表达
请求批量创建student信息excel文 响应header
Content-Type aplication/json
Content-Language可选 内容语言
Last-Modified 数据最近一次修改的时间戳信息 响应值
Success message多种类型
Error message多种类型
Exception多种类型 统一异常处理
统一异常处理包括状态码以及状态码涵盖的异常信息具体部分定义如下 200/201success message含资源数量信息uri信息创建成功适用于数量不多比如小于500的创建操作大于设定的值时进行异步处理参加返回值202 202success message with status uri异步处理返回进度查询资源uri/api/vendor/v1/status/{id} 400successerrors含出错项index的错误列表批量创建时部分成功返回成功信息和错误信息 401exception{error_codemessage}缺乏认证信息 403exception{error_codemessage}未授权访问访问被拒绝 406exception{ error_codemessage}不支持client要求的格式或语言时返回该信息Not Acceptable 415exception{error_codemessage}:请求中的文档格式不支持 422exception{error_codemessage}不能处理的数据比如json格式错误、文件内容项错误或会破坏业务规则 429exception{ error_codemessage}太多请求流控时使用 500exception{error_codemessage}服务器内部错误 统一日志拦截
基于AOP模式拦截所有请求在请求入站与出站的时候做统一日志记录以及需要的其他非业务处理例如鉴权 统一的数据返回标准
我们参考Restful数据返回标准封装我们自己的数据返回格式codemessagebodyerror统一的数据返回格式可以在接口层做统一的拦截处理。实现返回数据的标准化。 code返回状态码 message返回响应结果的语义解释 body响应的具体数据信息包括metada信息具体响应数据以及请求连接 error代表返回的错误信息 具体的响应格式如下所示
{code: 200,message: 获取学生列表成功,body: {links: [{rel: self,href: http://localhost:8080/api/cloud/v1/students?nameteststartDate2019-01-01endDate2019-09-01stylenormalsortasclimit10offset0{fields},hreflang: null,media: null,title: null,type: null,deprecation: null}],metadata: []content: [{id: 1,name: test3,status: running,props: test,remark: test,ownerId: 1,createrId: 1,menderId: 1,gmtCreate: 2019-03-11 10:42:15,gmtModify: null,startDate: null,endDate: null,links: [{rel: self,href: http://localhost:8080/api/cloud/v1/students/1?stylenormalfields,hreflang: null,media: null,title: null,type: null,deprecation: null}]}]}errors: {}} 服务接口的设计一定是围绕标准化的规则进行的这样才能在后期减少因为接口变动导致不断出现的前后端联调问题。因为在实践中我们经常遇到格式不统一导致web要写不同的数据解析方式从而造成大量重复的工作。 遗留问题 当然我们落地过程的选择也不一定尽善尽美也有很多随着业务处理能力的加强而在之前没有考虑到的问题例如 各个服务自身并发数据支撑能力 服务交互的内部代码瓶颈包括调用链路冗余响应偏慢等 数据库的并发支撑与性能优化 与容器服务集成的参数配置开发与部署环境的转变 调用链路可能出现的回环问题交叉的业务单元调用导致调用链路混乱 数据的缓存设计加快业务响应速率 这些问题我们在后续不断深入地理解和探索中会找到相应的解决方案大家可以在后续继续关注我们的微服务解决方案。 文章作者李宁
原文地址http://t.cn/Ei8hiuJ
