做过一段时间的后台架构，当时只是个小的公司用工具类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.