范文健康探索娱乐情感热点
投稿投诉
热点动态
科技财经
情感日志
励志美文
娱乐时尚
游戏搞笑
探索旅游
历史星座
健康养生
美丽育儿
范文作文
教案论文

微服务架构下的API接口驱动开发,设计和集成

  今天谈下在微服务架构下,接口设计和开发方面的思考。
  对于微服务架构,SOA和Http Rest API接口设计,在我前面的头条文章中均有专门的说明,因此对于基础方面的解释在本文不再重复。对于今天要写的内容,先总结一句话再展开说明。
  在SOA和微服务架构思想下,除了常说的面向对象,领域驱动,SOA等架构思想外。还需要增加基于API接口驱动进行的设计和开发工作。API接口的识别,定义,设计和开发过程贯彻了整个微服务开发的生命周期。软件生命周期
  对于软件开发过程或生命周期,常会说到瀑布模型,增量和迭代模型,敏捷方法论等。即使到了迭代开发,对于全新驱动仍然强调一个关键点,即:
  软件开发中应以架构为核心,架构应确保高度的概念一致性和完整性。
  也就是说对于全新系统研发,即使要拆分和并行,也需要在架构设计完成后再进行,否则很难真正保证架构一致性和整个领域模型的完整性等。
  从模块拆分到前后端分离
  对于传统业务系统的开发,架构做了一个重要工作,即将大的业务系统拆分为多个子系统或者模块,同时定义清楚各个模块之间的接口。在这个工作完成后,后续各个模块的设计开发工作才能够真正并行起来。也就是说:
  只要各个模块是按照预先定义好的接口进行设计开发的,那么最终各个模块就一定能够集成起来。架构师不单是做了分而治之的分解工作,而是通过接口解决了分解后的集成问题。
  即使到了现在微服务架构模式下,对于究竟拆分为多少个模块,每个模块应该暴露哪些API接口服务应该是自顶向下方式,由架构师统一进行规划和设计。
  微服务架构开发实际上重点解决两个阶段的关键问题规划设计阶段:通过架构设计来确定微服务拆分,关键接口API定义实现阶段:选择具体的某个微服务开发框架进行功能的开发实现
  其次,在微服务开发中,引入了另外一个关键即前后端分离。
  前后端分离实际和SOA思想里面的服务分层思路相对一致,至少SOA跨系统间的服务分层,服务组织思想进入到单个微服务内部的功能实现机制上。
  前后端分离实际上当前是包括了技术和团队组织两个方面在技术上前端和后端完全拆分,都可以独立编译打包在团队上形成前端和后端角色,不再是一个人前后贯通实现
  在分离后开发分工越来越细,各自都可以专注自己的内容做到更加高效,一个前端往往也可以对应多个后端开发。而前端和后端协同的关键就变成了Rest API接口服务调用。
  接口先行和驱动的开发
  那么当前微服务开发,有多少团队是真正将接口定义和设计清楚后,各自基于严格约定的接口契约进行并行开发的?
  实际上很多团队并没有严格这样做。
  前端说需要一个接口了,后端临时再做一个,或者后端因为另外一个功能实现影响将接口调整了也不通知前方等,这些都是实际经常出现的情况。
  即接口本身严肃性不够,导致接口新增和变更都相对随意,也导致了接口很难处于一个稳定的状态。在接口无法稳定的情况下,导致团队各个角色的开发都受到影响。
  接口驱动开发的核心思路就是在微服务开发过程中优先定义和设计接口,确定API接口模型和接口契约,然后后端,前端,基于同样的接口标准并行开展工作。
  接口定义清楚后,可以生成相应的代码框架或开发框架,前端和后端基于同样的开发框架进行接口开发工作。对于后端人员应该优先实现接口,再实现非接口部分内容,后端人员实现的接口可以自己进行单元测试。而对于前端在进行开发的时候,由于有了接口契约,可以通过Mock的方式提供模拟接口数据,方便进行前端功能开发和测试。
  只有这样,才能够真正做到全并行开发和开发后的集成工作。
  为什么接口驱动很难?
  实际在实践的过程中你会感觉到很难,就是前期定义接口往往在后期仍然大量变动和增加,但是这不是不用接口驱动的理由。就如我们不能因为需求会经常变更,而不先进行需求分析和开发一样的道理。
  接口频繁变动实际本身包括两个方面的原因。
  其一是需求本身就不清晰,往往是功能做到哪里想到哪里,这样自然会导致接口不断地增加或者变更,导致大量重复工作。其二是在进行接口定义设计的时候,没有考虑接口应该是提供领域服务能力,而不是提供大量的数据库表的CRUD能力,没有考虑很多逻辑应该是内聚在后端完成聚合和组装,而跑到前端进行组装。
  以上两个就是接口频繁变动的关键原因。因此要推进接口驱动,首先要加强需求输出的严谨性,其次要加强领域设计能力,做好接口的设计和抽象。接口驱动开发过程
  在这里先看下关于面向接口编程的一些说明。
  我们在一般实现一个系统的时候,通常是将定义与实现合为一体,不加分离的,我认为最为理想的系统设计规范应是所有的定义与实现分离,尽管这可能对系统中的某些情况有点麻烦。
  在一个面向对象的系统中,系统的各种功能是由许许多多的不同对象协作完成的。在这种情况下,各个对象内部是如何实现自己的,对系统设计人员来讲就不那么重要了;而各个对象之间的协作关系则成为系统设计的关键。小到不同类之间的通信,大到各模块之间的交互,在系统设计之初都是要着重考虑的,这也是系统设计的主要工作内容。
  面向接口编程就是指按照这种思想来编程。
  对接口的理解
  接口从更深层次的理解,应是定义(规范,约束)与实现(名实分离的原则)的分离。接口的本身反映了系统设计人员对系统的抽象理解。
  在设计模式里面经常会提到面向接口而设计,同时强调尽量要少用继承而多用组合。面向接口设计一方面是更加方便的应对和适配底层变化,比如底层实现的变化;另外一个方面就是接口定义清楚后对于接口依赖端可以并行开展工作。
  同时还可以看到通过面向接口编程方式,可以最大限度地对外部屏蔽接口内部实现细节,一个模块对外开放能力只需要开放接口定义格式和描述,而不用开放具体的实现细节。
  定义和实现分离,达到了进一步的安全方面要求。
  接口在架构设计中起到关键作用
  在前面已经谈到接口定义和设计在架构设计里面起到关键作用,这种接口的定义除了上述的作用外,更加重要的是实现了系统分解后,各个子系统和模块只要遵守共同的接口定义契约,就可以开始并行开发和实现。
  这也是我们在实施大型SOA集成项目经常谈到,接口定义和设计先行,通过统一标准的接口契约来实现接口开发和实现的并行。如下图:
  接口先行的目的就是大家遵循同样的标准,那么后续各个组件就能够无缝地集成到一起。否则接口实现不一致,那么后续就无法进行集成,导致功能和接口变更。
  基于接口驱动来实现完整的产品开发和集成
  在微服务开发过程中,整个微服务划分和微服务间的接口设计仍然需要保持高度的架构完整性和概念一致性。即首先通过架构人员进行微服务拆分,关键接口设计,其次才是进行各个微服务模块的开发,在开发完成后进行集成工作。
  如上图,大家遵循同样的接口契约,那么后端开发,前端开发和测试人员可以并行开始各自的工作。对于前端优先进行接口开发和实现,前端则通过接口契约产生Mock模拟,通过接口模拟实现来进行前端功能的开发。在前后端开发过程中,测试人员也可以根据接口定义进行测试设计工作,同时进行相关的测试脚本设计或录制工作。
  接口开发完成后,前端和后端首先各自进行单元测试,在单元测试完成后进行前后端的集成测试和验证。同时测试人员可以启动相应的接口自动化测试工作。
  前后端分离后的问题
  当我今天写这篇文章的时候,进一步思考了下前后端分离开发的一些问题。
  比如在传统开发模式下,一个功能实现都由张三负责,那么前端和后端都是张三来做,张三对整个功能业务和逻辑都了解,因此可以既完成接口层的单元测试,也可以完成前端页面黑盒驱动的功能自测试工作。
  当功能进行前后端分离开发后,张三仅负责后端,前端由小敏负责。
  而这个时候张三往往对整个前端功能实现和页面都不关心,仅仅关注自己逻辑实现和接口提供,关注自己的单元测试验证。而小敏负责前端,实际上小敏对整个功能的业务逻辑和场景往往也并不清楚,仅仅只能够测试数据的录入,查询装载等正常。
  即这个时候张三和小敏都无法完整地进行前端功能页面的测试,这个时候导致很多测试工作都转到测试阶段后由测试人员才能够测试和发现。
  这本身也就导致了功能实现问题的进一步朝后面泄露。
  如何解决这个问题?
  第一个方法就是负责后端的张三必须做完整的单元测试,而这个工作量极大,大部分开发人员实际都无法做完整的单元测试。第二个方法就是该工作还是由小敏负责,那么小敏就必须参与前期需求和接口评审,熟悉需求和业务场景,才能够展开。
  规模不大的项目没必要前后端分离
  这个也是我在前面强调过的要给观点,尽管前后端分离可以进一步实现微服务间的解耦,但是也增加了单个功能实现多个角色之间沟通的协同量。
  项目规模再小,你还得找到要给后端角色或前端开发两个角色,或者你需要找到一个很厉害的都懂的全栈人员。而实际上前后端分离本身带来大量的集成工作量,同时后端分离的API接口本身并没有体现出应有的粗粒度和复用价值。
  本来一个简单项目,前端用easyui就能搞定,结果用微服务和前后端分离后却越搞越复杂。Http Rest API接口设计
  对于HTTP Rest接口的设计,网上已经有很多文章都有详细的阐述,今天再重新整理下这里面的一些重点,大家都清楚Rest接口是面向资源的接口设计方法,而且基于原生的Http协议,因此里面就有两个最关键的点,一个就是对资源的理解,一个就是对操作的理解。
  图片来源网络
  什么是RESTful架构,重要的几点如下:每一个URI代表一种资源;客户端和服务器之间,传递这种资源的某种表现层;客户端通过四个HTTP动词(GET/POST/PUT/DELETE),对资源进行操作
  对资源的理解
  就是我们平常上网访问的一张图片、一个文档、一个视频等。这些资源我们通过URI来定位,也就是一个URI表示一个资源。资源是做一个具体的实体信息,它可以有多种的展现方式。而把实体展现出来就是表现层,例如一个txt文本信息,它可以输出成html、json、xml等格式,一个图片他可以jpg、png等方式展现,这个就是表现层的意思。
  URI确定一个资源,但是如何确定它的具体表现形式呢?应该在HTTP请求的头信息中用Accept和Content-Type字段指定,这两个字段才是对"表现层"的描述。
  对操作的理解
  客户端能通知服务器端的手段,只能是HTTP协议。
  具体来说,就是HTTP协议里面,四个表示操作方式的动词:GET、POST、PUT、DELETE。它们分别对应四种基本操作:GET用来获取资源,POST用来新建资源(也可以用于更新资源),PUT用来更新资源,DELETE用来删除资源。
  对于资源的任何操作,都应该映射到HTTP的几个有限的方法(常用的有GET/POST/PUT/DELETE 四个方法,还有不常用的PATCH/HEAD/OPTIONS方法)上面。所以RESTful API建模的过程,可以看作是具有统一接口约束的面向对象建模过程。
  按照HTTP协议的规定,GET方法是安全且幂等的,POST方法是既不安全也不幂等的(可以用来作为所有写操作的通配方法),PUT、 DELETE方法都是不安全但幂等的。将对资源的操作合理映射到这四个方法上面,既不过度使用某个方法(例如过度使用GET方法或POST方法),也不添 加过多的操作以至于HTTP的四个方法不够用。
  是否全用POST方法实现接口?
  在接口设计里面经常会遇到一个问题,即是否全部用POST方法来实现接口,如果图简单省事,那么全部用POST方法是最省事的方式。
  对于Get方法相对Post方法来说究竟有哪些优势?网上一段话可以参考如下: GET 的URL可以人肉手工在地址栏输入啊…你在地址栏打个POST给我看看。本质上面, GET 的所有信息都在URL, 所以可以很方便的记录下来重复使用。
  也就是说通过Get方法可以更好地方便测试,验证,缓存等。
  如果不考虑这点,确实可以完全用Post方法来实现所有Rest API接口。但是我们仍然建议对于简单的对象获取,根据Key值获取等仍然可以实现为Get方法。
  其次对于比较复杂的模糊查询,还涉及到排序,多条件过滤的,虽然网上也有Rest API规范来强调用Get方法如何来定义,但是我们仍然推荐还是采用POST方法通过Body传递更合适。
  反之,涉及到数据新增修改等操作,再简单也不建议通过Get方法进行。
  API接口的版本问题
  对于API接口的版本定义,仍然推荐在IP地址或域名后先定义版本,再定义详细的对象集合和ID信息。具体如下:GET https://{serviceRoot}/{collection}/{id}
  GET https://www.aa.com/v1.0/user/123/
  当然还有一种方法是在后面添加版本,比如:
  https://api.contoso.com/user/123?version=v1
  这种方式为何不好?
  即我们很难通过前面的接口定义和URL信息明确地知道究竟是消费哪个版本,而具体接口的版本信息必须动态在调用的时候参数化传递。
  那么我们就很难将显性化的细粒度控制到具体的版本。特别是在接口启用大小版本的情况下,实际上大小版本已经是两个输入输出有明显差异的服务,必须单独控制。
  包括用这种动态方式,API接口不同版本要注册接入到API网关本身也相当麻烦难以实现。当然如果你全部用POST方式实现接口,那么版本信息定义在路径末尾也是可以的,比如:
  https://api.contoso.com/GetPeopleByID/V1
  具体更加详细的说明可以参考微软的Rest API接口定义规范。方法和工具选择
  主流的Swagger设计工具
  对于设计工具,这里只谈下Swagger设计工具,这个工具最大的好处就是只需要通过编辑器进行Rest接口设计文件的定义,然后可以自动生成测试框架,自动生成客户端和服务端多种语言下的开发框架,生成API接口设计文档,这个工具本身设计完成内容还可以导出为YAML文件或Json文件,也支撑文件导入。
  在采用Swagger工具的时候,我们希望的步骤为:
  首先是通过Swagger Editor进行接口文件的定义,对于接口文件本身的定义建议仍然进行分域而不是全部都定义到一个文件里面。
  其次基于接口定义,通过Swagger提供的CodeGen功能来生成RestClient,或者整个SpingBoot项目。这个生成既需要包括客户端消费框架,也需要包括服务提供端框架。类似原来基于WSDL文件,用CXF框架来生成代码框架一样。
  注意网上也有Spingcloud框架来集成Swagger的文章,更多的则是对已经定义好的接口来生成API接口文档,这并不是完整的接口驱动开发。
  再次,通过接口定义来自动生成Mock数据,可以通过Swagger Json文件定义格式在前端通过JS来产生mock数据,也可以搭建一个完整的Mock Server产生数据,在这个步骤完成后,前端开发人员可以开始并行开发工作。
  最后,API接口文档生成,Swagger在完成了接口定义后本身就已经形成了完整的接口定义,这个定义本身可以导出为完整的Html文档,也可以自己写代码进一步自动转化为Word文档。
  即基于Swagger这类工具,再加上少量的定制,基本就可以实现一个完整的接口驱动开发中所需要的所有文档,代码开发框架等。

瞄准与隐秘而伟大最全面优缺点对比,看看哪部更适合你给近期两部比较优秀却各有优缺点谍战片瞄准与隐秘而伟大做个全面对比!剧情方面两剧都是以给前线提供情报作为出发点!隐秘主要讲男主的成长!所以前线这条支线是隐藏的!这也是该剧比较弱的地方人民的名义2之巡回检察组刷情炸裂!于和伟令人惊喜!年末就是热闹!巡回检察组(又名人民的正义)空降开播!这部由人民的名义原帮人马出演的姐妹篇可谓是来势汹汹,除了吴刚许亚军侯勇丁海峰李学政许广冯雷等将近20人的老戏骨悉数回归,新加入的一个案件引发社会五大潜在痛点!值得看的女性焦点剧迷雾追踪一个案件引发当今社会五大潜在痛点网约车安全问题,女性就业问题,网络暴力问题,职业潜规则问题,以及各种形形色色的家庭问题。一部以女性为主焦点的悬疑剧场迷雾追踪开播。护士李佳佳深夜网约作为武侠剧,动作设计上很败笔!有翡要高开低走了!由王一博和赵丽颖搭档的大型武侠古装剧有翡千呼万唤终于搭上2020的末班车,在12月16号开播,这部重磅级大型古装剧在推广宣传方面可是下足了功夫的!产后复出的赵丽颖也可是有收视保障的了不起的儿科医生借用儿科,道尽了生活的无奈与残酷!了不起的儿科医生致敬医生面对的不仅仅是能不能救治病人的问题,更多的客观因素比病魔更可怕!了不起的人不管是医生,病人,还是家属!面对困难最矜贵的是坚持!借用儿科道尽了生活的无奈与残酷不要把注意力集中在谁是反派上巡回检察组表达了更复杂的一面人民的名义姐妹篇巡回检察组上线后,大家更多的是把精力放在谁是反派上。其实该剧可不是纯粹的捉反派捉内鬼而已!该剧更讲究的是人性的根源!吴刚饰演的宋志明对韩童生饰演的张友成说了这么一句大江大河2探讨人性的直白及制造行业的无奈!大江大河2内容是无缝衔接大江大河1的,宋运辉壮志豪情来到了东海,不过他肯定没想到棘手的问题来得如此之快!也让我们直接感受到了其实他所面对的问题,虽然已经几十年过去了,但目前基本上还巡回检察组之当一个好官,真的好难!有种违规叫被违规!巡回检察组又名人民的正义率先出场的张友成书记真是让人感概万千!有多少人的梦想就是想当一个清官,为民造福!但最后却发现自己不知不觉在初衷的路上越走越远,还有一种违规,叫被违规!从前十大秦赋会还原吕不韦自尽的真相吗?并不是功高盖主!很多时候,在无意中我们会觉得吕不韦更像是个反派人物!会为22岁的秦王政铲除吕不韦的事迹而不禁喝彩!就算不觉得他是反派也不会为他的死觉得可惜!一生鞠躬尽瘁的吕不韦为什么会让人对他如此瞄准里的水母组的7个成员代表反派的七宗罪!瞄准已大结局了!最强水母组也已全员下线!其实水母组的每个成员,包括他自己,在领饭盒的情节中,都能让人感受到一种很特殊的情绪,而这种情绪更像是人的劣根!和尚的死是无奈的!!他害怕死,了不起的儿科医生这残酷的剧情,有多少想当医生的会被劝退?一般反腐反黑剧起到的作用是警戒上这条道的人一定要洁身自好!一步踏错一辈子可能就毁了!一般职场剧,让人感受到的是毅力与坚持,让人在感同身受的同时起到鼓励的作用!但了不起的儿科医生身为
官至省委书记掌管黄金银元,沿路乞讨也不挪用分毫,贫病而死兴国县是全国著名的红军县将军县,肖华陈奇涵朱明等开国将军都是兴国县人,兴国县牺牲的红军战士有5万多人,他们许多人没有留下名字,这其中有许多鲜为人知的感人故事。今天要介绍的刘启耀就是蒋介石亲自挑选的侍从参谋,竟是地下党,断送老蒋半壁江山革命时期,潜伏在国民党的红色地下党不在少数,如被誉为按住蒋介石脉搏的人沈安娜,以及熊向晖等人,他们都是了不起的红色特工,还有一位红色特工比他们更为传奇。这位传奇的红色特工就是段伯宇上甘岭战役王近山三天没睡,听说此人上阵了,立马倒头大睡说起抗美援朝就不得不提起上甘岭战役,此战可以说是整个抗美援朝战争中最为惨烈的一次战斗,双方鏖战43天,志愿军打退了美军900多次冲锋,最终取得胜利。上甘岭战役打响的时候,第三兵团司志愿军中的模范团长,山头被炸掉一截,他亮出最后的底牌说起抗美援朝有说不完的故事,在志愿军队伍中不得不说万岁军38军,而在38军中又不得不说335团,而说起这个团就不得不说起他们的团长范天恩,他被授予模范团长称号。范天恩绰号范大胆,他他出卖老上司获蒋介石欢心,对日军不战而逃,却官拜一级上将抗日名将薛岳晚年曾感叹,蒋介石用人宁用奴才,不用人才!一方面是对自己一生的喟叹,另一方面也是对那些一无是处却忝居高位的人的一种讽刺,这其中的典型就是余汉谋。余汉谋是一个没有真材实料129师师部遭日军偷袭,刘帅险些被擒,关键时刻他率军赶到提起三国时期的赵子龙,是无人不知无人不晓,长坂坡雄风传千古,千年后在八路军的129师中也出了一个赵子龙,此人就是令日军胆寒的周希汉。周希汉是湖北麻城顺河镇人,1927年,14岁的周此上将在贵州5年,剿灭土匪27万余,改变当地缺粮的困境许多人都看过大西南剿匪记之类的剿匪战争剧,反映了英勇的解放军为剿匪安民做出的贡献,甚至还有一位开国上将因剿匪而闻名,他就是苏振华上将。提起苏振华上将是湖南平江县人,出生在一个穷苦的军统少将沈醉被特赦,享副部级待遇,他为何要冒险去祭拜戴笠在军统局里面,沈醉以年纪小资格老而著称,与周养浩徐远举并称军统三剑客,年纪轻轻的沈醉就成为军统少将,深得戴笠的信任,他和戴笠之间有着一段不为人知的往事。沈醉是湖南湘潭市人,1932她是双枪老太婆的原型,终身守寡闹革命,死后22年恢复党籍不少人都看过红岩,对里面的双枪老太婆影响深刻,后来还被搬上了银幕,一时间双枪老太婆成了家喻户晓的女英雄,却很少有人知道双枪老太婆的原型陈联诗。根据红岩小说作者之一的罗广斌证实,双枪破冰行动林耀东的原型,三千警力犁庭扫穴,抓获冰毒教父最近破冰行动大火,似乎胜过之前播出的人民的名义,该剧在播出时有一行醒目提示本剧根据真实事件改编,谁能想到如此触目惊心的缉毒案就发生在我们的现实生活中。作为剧中最大的毒枭林耀东,他一真实的哈儿师长,击毙日军中将师团长,妻妾7人活83岁曾经一部傻儿师长红遍大江南北,也人许多人认识了范哈儿,却很少有人知道历史上真实的哈儿师长,他的名字叫范绍增,是傻儿师长的原型人物。范绍增是四川大竹县清河镇人,他出生在一个富裕的大家