微服务规范.doc

微服务规范.doc

ID:20744881

大小:452.90 KB

页数:26页

时间:2018-10-15

微服务规范.doc_第1页
微服务规范.doc_第2页
微服务规范.doc_第3页
微服务规范.doc_第4页
微服务规范.doc_第5页
资源描述:

《微服务规范.doc》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库

1、微服务规范关于微服务3概念和定义3组件与服务3去中心化和集中架构4围绕业务功能进行组织5产品不是项目 5强化终端及弱化通道5分散治理5分散数据管理6基础设施自动化6容错性设计6设计改进6其它7微服务与SOA7多语言,多选择7实践标准和强制标准7原则8Availability:标准的目标8Production-Readiness标准8Stability8Reliability8Scalability9FaultTolerance9Catastrophepreparedness9Performance9Monitoring10Documentation10服务化架构的演进

2、历史10历史10MVC10RPC10SOA11微服务架构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关于微服务概念和定义简单来说

3、,服务的本质就是行为(业务活动)的抽象。对于SOA,推进结构化信息标准组织(OASIS)和开放团体(OpenGroup)均给出了正式定义。OASIS将SOA定义为:Aparadigmfororganizingandutilizingdistributedcapabilitiesthatmaybeunderthecontrolofdifferentownershipdomains.Itprovidesauniformmeanstooffer,discover,interactwithandusecapabilitiestoproducedesiredeffectscon

4、sistentwithmeasurablepreconditionsandexpectations.OpenGroup将SOA定义为:Service-OrientedArchitecture(SOA)isanarchitecturalstylethatsupportsservice-orientation.Service-orientationisawayofthinkingintermsofservicesandservice-baseddevelopmentandtheoutcomesofservices.Aservice:lIsalogicalrepresent

5、ationofarepeatablebusinessactivitythatlhasaspecifiedoutcome(e.g.,checkcustomercredit,provideweatherdata,consolidatedrillingreports)lIsself-containedMaybecomposedofotherserviceslIsa“blackbox”toconsumersoftheservice业界基本的认知是,SOA是一种架构模式,是一种面向服务的思维方式。对于服务的定义,OpenGroup认为服务是一种可重复的业务活动的逻辑上的描述,是

6、一种自包含的、可组合的“黑盒子”。微服务在服务定义上,与传统的SOA差别不大,在实现上强调应用的颗粒度足够小,当然小到什么程度也是争论的一个话题。在我看来,微服务“微”的并不是服务,其实微的是应用(后面我们会谈到,服务的颗粒度是和需求相关的,是不能随意变大变小的)。组件与服务组件是指软件中独立的单元,它能独立替代和独立更新。微服务架构也使用组件库,但是它把软件拆分成服务,并认为这是主要的组织形式。我们把组件库定义为程序中相互关系、并使用内存中调用的组件,把服务定义为进程间使用如Web请求服务或者远程调用来相互通信的组件。(这种定义的方式与其它面向对象程序中服务对象的概

7、念是不一样的。)把服务当成组件(而不是组件库)一个主要的原因是服务可以独立的部署。如果你的应用由多个组件库组成并跑在一个进程中,那么任何组件的变更都将导致整体应用的重新发布。但是如果由许多服务构成的应用,你可以想像的到每个服务的变更仅需要发布相应的服务。当然,这也不是绝对的,比如导致服务接口的变更的更新就需要相应服务的变化,但优秀微服务构架,会尽量避免这种服务间的耦合并完善服务的交互接口。把服务当成组件的另一个考虑是这将拥有更新清晰的接口。许多开发语言并没有良好的定义公共接口的机制。通常只有文档和规范说明,让用户避免组件间会导致组件耦合的过度的依赖。

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。