微服务规范
关于微服务 3
概念和定义 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定义为：
Aparadigmfororganizingandutilizingdistributedcapabilitiesthatmaybeunderthecontrolofdifferentownershipdomains.Itprovidesauniformmeanstooffer,discover,interactwithandusecapabilitiestoproducedesiredeffectsconsistentwithmeasurablepreconditionsandexpectations.service fault
OpenGroup将SOA定义为：
Service-OrientedArchitecture(SOA)isanarchitecturalstylethatsupportsservice-orientation.Service-orientationisawayofthinkingintermsofservicesandservice-baseddevelopmentandtheoutcomesofservices.
Aservice:
●Isalogicalrepresentationofarepeatablebusinessactivitythat
●,checkcustomercredit,provideweatherdata,consolidatedrillingreports)
●Isself-containedMaybecomposedofotherservices
●Isa“blackbox”toconsumersoftheservice
业界基本的认知是，SOA是一种架构模式，是一种面向服务的思维方式。对于服务的定义，OpenGroup认为服务是一种可重复的业务活动的逻辑上的描述，是一种自包含的、可组合的“黑盒子”。
微服务在服务定义上，与传统的SOA差别不大，在实现上强调应用的颗粒度足够小，当然小到什么程度也是争论的一个话题。在我看来，微服务“微”的并不是服务，其实微的是应用（后面我们会谈到，服务的颗粒度是和需求相关的，是不能随意变大变小的）。
组件与服务
组件是指软件中独立的单元，它能独立替代和独立更新。
微服务架构也使用组件库，但是它把软件拆分成服务，并认为这是主要的组织形式。
我们把组件库定义为程序中相互关系、并使用内存中调用的组件，把服务定义为进程间使用如Web请求服务或者远程调用来相互通信的组件。（这种定义的方式与其它面向对象程序中服务对象的概念是不一样的。）
把服务当成组件（而不是组件库）一个主要的原因是服务可以独立的部署。如果你的应用由多个组件库组成并跑在一个进程中，那么任何组件的变更都将导致整体应用的重新发布。但是如果由许多服务构成的应用，你可以想像的到每个服务的变更仅需要发布相应的服务。当然，这也不是绝对的，比如导致服务接口的变更的更新就需要相应服务的变化，
但优秀微服务构架，会尽量避免这种服务间的耦合并完善服务的交互接口。
把服务当成组件的另一个考虑是这将拥有更新清晰的接口。许多开发语言并没有良好的定义公共接口的机制。通常只有文档和规范说明，让用户避免组件间会导致组件耦合的过度的依赖。不过服务由是是通过明确的远程接口调用，这个问题就很容易解决了。
使用服务也有它的不足之处。远程调用比进制内部调用更消耗性能，而且远程的API比较粗糙，难以使用。如果由于对组件的职责进行变更，影响到跨进程间的交互，那么这操作起来也比较困难。
第一个可能的特性，我们看到每个服务是运行在独立的进程上的。注意，这只是第一个可能的特性。服务也可以由多个进程组成，它们是同时开发和部署的，例如服务可能用到一个应用进制和一种数据禀。
去中心化和集中架构
SOA发展过程中既有无中心架构，也有集中架构，前者用于互联网企业间的交互，后者在企业内部使用。
确切的讲SOA没有“去中心化”架构，只有“无中心化”架构。
架构是为了实现特定的目标的，而这目标源于需求和现实，那么”无中心化“架构就是SOA在互联网环境下的必然的架构选择。其实也没得可选，因为SOA要解决企业间的通过互联网相互访问的需求，而互联网是一个自由的无政府环境，根本就不存在一个共同认可的架构中心节点。两者对比如下：
去（无）中心 | 集中 | |
组织形态 | 无政府 | 有政府 |
组织能力 | 不可能建立中心节点 | 可以建立中心节点 |
协议约束 | 必须统一协议 | 可以不统一协议（成本低） |
安全策略 | 必须统一安全策略 | 安全策略多样化 |
管控能力 | 无法做到统一管控 | 组织需要并可以做到统一管控 |
其实无论是去中心还是集中架构，都是组织需要而非技术需要，需求决定技术架构。在企业内部，无论任何架构都要满足组织对管控的需求，而这种需求必须由一个统一的中心节点来提供，所以SOA化在组织内部大多数是以ESB作为基础来实现的。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论