常用微服务架构SBA--以服务为基础的架构
做过⼀段时间的后台架构，当时只是个⼩的公司⽤⼯具类app后台，并发⼩，业务简单，当时就快速简单的完成了，但是架构设计⽅⾯还是要好好学习的。2015年微服务架构和restful架构风格⼤⾏其道，⼀直想搞明⽩mircoservice和soa这两者到底有什么关系，然后在nginx 官⽹发现了⼀本书，那么就来开始研究。
本篇从两者的共同开始讲起，SBA(Service-base architectures)以服务为基础的架构，不管是mircoservice还是soa，他们都是这类的架构。
先看⼀张总结的图
简介
以服务为基础的架构，service占据重要的位置，他们的架构模式往往是以服务为第⼀重要的架构组件，来实现平台业务或者⾮业务相关的功能。
在我看来服务是资源拥有者，这⾥的资源可以是硬件，⽐如虚拟主机，也可以是算法，⽐如在线的⼈脸识别服务。其为需要服务的客户提供服务。
契约(Service Contracts)
客户和服务之间进⾏服务这个过程是需要信息沟通的，就想外贸⼀样，在⼀定的契约之下，才能进⾏有效的沟通。说⽩了就是传输的业务数据协议。
service和consumer之间沟通，⼀般两种情况。
service决定和consumer决定。这两则的不同在与协同程度的不同，service决定，那么其契约的修改就不需要考虑客户端，占有主动地址，反过来，consumer也是这样，⽽且更⿇烦，service适配consumer，需要service知道consumer选择的契约，那么还需要⼀种共同标准来协调。
那么对于同⼀个契约，可能也有改变，有些客户还在⽤⽼的契约，⽽新近的客户在使⽤较新的契约，那
么contract versioning就可以使⽤，在版本上⾯，不是简单的１，２这么简单，需要统计契约的同性和异性，⽐如都是第⼀版本，但是⼀个是最初的１版本，⼀个是２版本，那么就是V1.1和V1.2。
这⾥说说契约有那些:XML,json,jave object,google protobuf等等。
Service Availability
SBA⼀般在⽹络环境中使⽤，那么既然在⽹络环境中，那么就可以存在service不可使⽤的问题(service availability)；同理，对于客户来说你也将⾯临不能获得响应的问题(service responsiveness)。
这两种情况下，都将导致整个服务流程失败，在这种情况下，那么我们该怎么办？
当service不可⽤时，客户端⼀般是多次重试或者将请求进队，等service可⽤时在做操作。
对于service responsiveness来说，⼀般出现在service⾼负载的情况下，不能及时的响应consumer，那么是客户端是⼀直等还是超时了？超时那么时间该是多少了？
书中提到了⼀种circuit breaker pattern，这个这⾥不具体描述，其就是为了减少客户端⽆谓的等待。
全局的超时时间是很烂的⼀个想法，我们的超时时间需要⾃⼰维护⾃⼰的变换⽽且是可以配置的，不然
你还需要重现编译的程序。超时时间应该根据前⾯请求的响应事件，当前的⽹络状况和系统负载来决定，tcp会告诉发送端对⽅的接受窗⼝，那么我们在service回复的响应中也可以带上负载信息来影响consumer的超时状态。
Security
在⽹络上提供服务，对于⼀些具有特殊意思的服务，需要检测客户是否是认证(authentication)的合法客户，那么对于服务细则这个认证客户是否有授权(authorized)，⽐如有些可以有该数据的权限⽽有些没有。
对于SOA来说，安全是很⼤的⼀个主题。安全作为⼀个基础的功能，被整个业务共享。关于这个问题⼜引出了我们怎么保护我们的服务怎么不被那些不应该访问的客户访问。
在微服务中，安全⾯临着⼀些挑战，没有⼀个中间件可以处理安全相关的功能。⼀般是每个微服务⾃⼰处理，或者在⼀些情况下，API层是⼀个很好的地⽅来处理这类问题。在微服务中，⼀种实现是，提供⼀个认证微服务来进⾏全局业务的认证，⽽授权则由各微服务⾃⾝来决定。
Transactions
数据传输在SBA中是⼀个⼤的挑战。SBA⼀般都是分布式系统，那么⼀个服务请求可能跨越⼏个service。
我们希望我们的⼀次操作和数据库操作⼀样，具有ACID属性，但是有时是不可⾏的。⽐如⼀个consumer完成⼀个Task A需要访问service B和service C，那么其分为两次请求，那么具会出现，B成功，C失败的情况，那么操作B我们希望撤消。
但是对于微服务，我们在设计的时候就重复将业务分离，⼀个请求只做⼀件事。
除了使⽤ACID，SBA还使⽤ BASE transactions。其是⼀组风格的集合，包括基本的可⽤性(basic availability)，软状态( soft state)，和最终的⼀致性( eventual consistency)。分布式系统要求最终效果的⼀致性，⽽不是像数据库那样的每个事务的⼀致性。BASE transactions最好的例⼦是在ATM上完成⼀次转账的操作。
在SBA中思考交易和⼀致性。在你⽆法保证最终的⼀致性，那么你只有加⼤业务划分的粒度，让⼀个service完成封装，这样来达到事务级的⼀致性。
[参考⽂献]
1. Mark, Richards. Microservices vs. Service-Oriented Architecture[M]. USA: O’Reilly, 2015.

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。