服务分类学
服务分类学指的是在某种架构下服务是如何归类的。有两种服务分类的基本类型：服务类型和业务领域。服务类型分类法会根据整个架构中服务所扮演的角色进行分类。例如，某些服务是实现业务功能的，而另一些服务可能是实现非业务功能的，例如日志、审计和安全。业务领域分类法会根据服务在特定业务功能领域中所扮演的角色来进行分类，例如报表、交易处理和订单送货等等。
服务类型分类一般在架构模式层进行定义，而业务领域分类则在架构实现层进行定义。尽管架构模式提供了很好的基础来定义服务类型，作为一个架构师，你可以按照自己的想法对其进行修改，定义自己的分类方法。本节中，我们会关注架构模式以及在微服务和SOA中比较常见的服务类型。
微服务架构就服务类型而言其分类法并不复杂，一般来说主要有两类服务类型，如图2-1所示。功能服务（functional services）是指用来支持特定业务操作或功能的服务，而基础服务（infrastructure services）则负责支持非业务工作，例如认证、授权、审计、日志和监控。在微服务架构中，这是非常重要的区别，因为基础服务并不对外开放而仅作为供内部使用的私有共享服务，对其它服务可用。功能服务则提供外部访问能力，而且不对其它服务共享。
图2-1
SOA内的服务分类法跟微服务有很大不同。在SOA中，从全局架构来看有非常明确的、非常正式的服务类型，各自在整体架构中扮演不同角色。尽管在SOA中可以有任意数量的服务类型，架构模式定义了四种基本类型，如图2-2所示：
图2-2
业务服务（business services）是一种抽象的、高层级的、粗粒度的服务，定义在企业层面的执行的核心业务操作。因为抽象，所以不依赖于任何实现或者协议，一般只包括服务名字，期望的输入以及期望的输出。可选地，这些服务类型还可以包括处理步骤或者跟服务相关的特殊编排规则。业务服务一般都用XML、Web Services Definition Language（WSDL）或者Business Process Execution Language（BPEL）等语言来表述。一般确认某个服务是否属于业务服务会在服务名上下文前后加上“我们是否在做某某的业务”来加以判断。例如，有两个服务，分别名为ProcessTrade（处理交易）和InsertCustomer（插入客户）。那么“我们是否在做处理交易的业务”可以很清楚看出ProcessTrade是一个业务服务；而“我们是否在处理插入客户的业务”听上去就不对，所以不是一个好的业务服务抽象，更像是一个在处理业务服务时所调用的某个具体服务。
企业服务（enterprise services）是具体的、企业层级的、粗粒度的服务，用以实现业务服务所定义的功能。如图2-2中所示，一般是介于抽象业务服务和对应具体企业服务实现之间的中间件，在其间起到桥梁作用。企业服务可以与业务服务之间存在一对一或一对多的对应关系。
它们可以用任何语言和平台进行定制，或者采用第三方采购的产品（COTS）来实现。企业服务很独特的一点是它们通常会在组织内共享。例如，一个RetrieveCustomer（检索客户）的企业服务可能被组织内很多模块使用，用来接收客户信息。其它例如CheckTradeCompliance（检查交易合规） , CreateCustomer（创建客户）, ValidateOrder（验证订单） 和 GetInventory（获取库存目录）等都是企业服务很好的例子。企业服务通常依赖应用服务（application services）和基础服务（infrastructure services）来完成特定业务请求。但是在某些情况下，某个企业服务也可能把完成特定请求所需要的所有业务功能都归入自身，形成自包含的服务。
应用服务（application services）是细粒度的、特定于具体应用的服务，与某个特定应用的语境相关。应用服务提供在企业服务中没有的特定的业务功能。例如，一个大型保险公司汽车报价应用可能提供服务来计算汽车保险费率。这是一个只针对该应用而并不适用于整个企业的服务。应用服务可以从某个专用的用户界面直接调用，或者通过某个企业服务调用。应用服务的例子包括：AddDriver（添加司机）、AddVehicle（添加车辆）以及CalculateAutoQuote（计算机车报价）等等。
SOA中最后一个基本服务类型是基础服务（infrastructure services）。与微服务架构相同，这些服务用于实现非功能性任务，例如审计、安全和日志。在SOA中，基础服务可以从应用服务或者企业服务调用。
需要记住的是，作为一个架构师，你既可以使用架构模式所提供的标准服务类型，也可以完全抛弃他们创建自己的分类方式。不管采用哪种方式，重要的事情是要确保针对架构存在定义良好且文档齐备的服务分类法。
服务责任制与协调
服务责任人（service owner）是组织内负责创建和维护某个服务的组别的类型。因为微服务架构仅支持有限的服务类型（功能服务和基础服务），应用开发团队一般都会同时负责这两种服务。尽管大量应用开发团队可能负责编写服务，需要了解的是他们都属于同一组别类型（即应用开发团队）。图2-3展示了微服务的服务责任制模型。
图2-3
对于SOA而言，一般对不同服务类型有不同服务责任人。业务服务的责任人通常是业务用户，而企业服务的责任人大多是是共享的服务团队或者架构师。应用服务的责任人一般是应用开发团队，基础服务的责任人一般是应用开发团队或者基础服务团队。中间件在SOA架构中经常使用，尽管不是一种服务，其责任人一般是整合架构师或者中间件团队。图2-4展示了SOA架构下服务责任制模型。
图2-4
服务责任人的重要性体现在全局的服务协调。在SOA中，必须在创建或维护某个应用需求的时候在多个组之间进行协调。关于抽象的业务服务必须咨询业务用户，关于完成业务服务功能所需的企业服务必须咨询共享服务团队，应用开发团队之间必须相互协调才能保证企业服务可以调用底层功能。同样，必须协调基础团队来确保非功能性需求能够通过基础服务得到保障。最后，所有这些都需要与中间件团队或者管理消息中间件的整合架构师进行协调。
在微服务场景中，完成某一业务请求通常只需要很少甚至完全不需要对多个服务进行协调。如果需要在多个服务责任人之间进行协调，也可以通过规模较小的应用开发团队快速而高效地完成。
微服务和SOA在服务责任制和总体协调上的不同直接决定了两种架构模式下开发、测试、部署和维护服务上所需要的精力和时间。在这个问题上，微服务模式表现突出。因为服务比较轻量，各个组之间协调最少，服务可以很快被开发、测试、部署。而这些优势最终又转化为较短的投放市场周期、较低的开发和维护成本以及和更稳定的应用。
服务粒度
从服务角度来看微服务和SOA的最大区别在于服务粒度。如名字所示，微服务是规模较小的、细粒度的服务。更确切地说，微服务架构中的服务组件一般都是单一目的/用途的服务，只做一件事且做到极致。而对于SOA而言，服务组件规模相差可以很大，可能是很小的应用服务，也可以是很大的企业服务。实际上，很常见的一种情况是SOA架构中的某个服务组件是由一个很大规模的产品或者一个子系统来提供。
有趣的是，SOA一开始碰到的最大挑战来自于服务粒度。如果不理解服务粒度影响，架构师很可能会设计粒度过细的服务，导致太多信息交互而影响整体性能。架构师和组件设计师很快学习到大规模的、粗粒度的、提供多种数据视图的服务是更好的服务模式。例如，相比较于太细粒度的数据读写服务，像GetCustomerAddress（获得客户地址）、GetCustomerName（获得客户名称）、UpdateCustomerName（更新客户名称）等等，架构师和共享服务团队更愿意采用部署企业级Customer（客户）服务的做法，用于处理更多粗粒度更新和接收数据视图，而把底层数据读写功能委托给并未开放给外部企业的应用级别服务。通过这种方式，像GetCustomerDemographics（获得客户统计数据）或者GetCustomerInformation（获取客户信息）之类的操作会返回一批客户数据，而不是单一的数据字段。
粒度不同自然是跟服务组件的作用范围和功能差异相关。对于微服务而言，服务组件的功能（服务作用范围）倾向于做得较小，有时通过一两个模块就可以完成。对于SOA，服务倾向于包含尽量多的业务功能，有时会作为子系统（例如，索赔处理引擎或者库存系统）来实现。不过，SOA通常依赖于多个服务完成单个服务请求，而微服务却并不这样。我会在下一章的“服务编排”一节中详细讨论这个问题。
无论使用微服务架构还是SOA，选择合适的粒度来设计服务并不是件容易的事情。服务粒度既影响性能也影响事务管理。服务的粒度太细时需要服务间通信来完成单一业务请求，从而导致大量的远程服务请求，占用掉宝贵的时间。假设访问某服务时花在远程访问协议上的时间是100毫秒，如图2-5所示，仅仅花在数据传输上的时间就达到600毫秒。如果将这些服务整合到一个服务中，将会将传输时间减少为200毫秒，这样总处理时间将会减少一半。
图2-5
服务粒度也会影响事务管理。这里我指的是传统的ACID事务，而不是前一章提到的BASE事务。如果远程服务的粒度太细，如图2-6上图所示，就不能使用一个事务工作单位来协调这些服务。然而，如果把这些服务组合进一个较大规模的远程服务中，如图2-6下图所示，这时你就可以用一个事务来协调这些服务，从而确保数据库更新可以在一个事务工作单位内完成。
图2-6
在处理服务粒度时，我发现从粗粒度服务开始会更容易一些。随着对服务的用法的了解逐渐增加，不妨再考虑如何对其进行拆分。如Sam Newman在Building Microservices书中所说，“从少数几个大服务开始”。只需要观察事务问题和服务之间通信量，尤其是在微服务架构下，如果发生相关问题很可能说明服务可能粒度太细了。
粒度与模式选择
本章所描述的三个服务特性中，服务粒度在根据情况进行架构模式选择的过程中具有最重要的潜在影响。微服务中规模很小的、细粒度的服务概念使得这种架构模式能够提升软件开发生命周期中的各个方面，包括开发、测试、部署和维护。尽管采用粗粒度服务肯定会解决性能和事务问题，这一转变反过来肯定也会给开发、测试、部署和维护带来负面影响。如果发现服务规模从小变大，那么最好选择SOA模式而不是更为简单的微服务架构模式。不过，如果能够将应用的业务功能分解为很小的、互相独立的部分，微服务模式应该是更好的选择。
当比较微服务和SOA架构时，除了以上服务特性外，还有很多其他方面需要考虑。下一章中，我们会更多地从全局角度比较这些架构方面，包括每种模式下组件共享水平、服务编排与布置、使用中间件或简单API层以及如何访问远程服务等方面的不同。
