共计 8511 个字符，预计需要花费 22 分钟才能阅读完成。
在设计服务中心的过程中，对服务中心内服务接口和数据模型的设计十分重要，良好的设计准则和办法能够最大化地保障服务中心的可扩展性。
强烈建议读者学习驰名建模专家 Eric Evans 最具影响力的著述 Domain-Driven Design-Tackling Complexity in the Heart of Software（《畛域驱动设计：软件外围复杂性应答之道》）以及 Thomas Erl 的著述 SOA principles of Service Design（《SOA 服务设计准则》），在理论的服务中心设计过程中，大多数状况下都可参考这两本书中的准则和办法。本书的目标是从全局的视线介绍如何更好地进行数字化企业的建设，所以不会深入探讨这个技术。
Façade(外观)模式
接下来在介绍服务化设计准则时，会屡次呈现 Façade 模式。
外观模式的应用原理如图 4 -11 所示。
外观模式的长处如下：
- 涣散耦合：外观模式使得前台利用与中台服务中心能够进行涣散耦合，让服务中心外部的模块能更容易地扩大和保护。
- 简略易用：外观模式让服务中心的服务更加易用，前台利用不再须要理解服务中心外部的实现，也不须要跟服务中心外部泛滥的功能模块进行交互，只需跟外观类交互就能够了。
- 更好地划分拜访档次：通过正当应用外观模式，能够更好地划分拜访的档次，有些办法是对系统外的，有些办法是零碎外部应用的。把须要裸露给内部的性能集中到外观中，这样既不便客户端应用，也很好地暗藏了外部的细节。
DTO 的应用
DTO 能够将服务中心简单或易变的数据对象对前台利用屏蔽，让前台具备更好的稳定性。DTO 是零碎分层设计和服务化架构中常常应用的技术，概念自身也容易了解，如图 4 -12 所示。
服务接口的设计准则
业务中台架构的外围是各个业务畛域的设计建模以及服务接口的设计，笔者联合业界优良的设计准则以及本人的实际，将服务接口典型的设计准则整顿如下，供各位读者参考。
1、契约后行
服务间的交互相似于不同组织之间的单干，依照失常逻辑，两个组织之间单干的首要任务就是先签订明确的契约，具体规定单方单干的内容、单干的模式，等等，这样能力对单方造成强有力的束缚和保障，同时工作也可能并行不悖，不必互相期待。因而服务化架构中最佳的实际形式也是服务契约后行，即先做服务契约的设计。在进行服务接口设计时须要有业务、产品和技术等不同方面的人员独特参加，并定义出相应的契约，而后再实现具体的代码。
在理论的中台架构设计阶段，当在企业不同的业务部门收集到业务需要，造成产品需要调研文档后，须要从全局的视角对服务中心的服务接口进行兼顾设计，即不是依照繁多利用场景，如仅从电商或仅从 CRM 零碎的角度，进行服务接口设计。尽管这些前台零碎都是依照步骤逐渐建设起来的，但服务中心的接口设计首先须要在全局的业务视角下进行布局和设计，有了清晰的接口设计，前台和服务中心就有了清晰而绝对稳固的交互边界，就能大大降低前期实现和经营期的合作老本，总体效率更高。
因为服务的用户范畴很广，在服务契约公开公布之后就要保障良好的稳定性，不能轻易重构，即便降级也要思考尽可能地向下兼容性。
2、服务性能内聚
服务性能内聚简直是任何服务化设计中最根本的要求。要创立性能内聚的服务接口，应该使性能相干的一组操作聚合到一起，同时必须将可能影响到业务正确性的逻辑在对应的服务中提供，而不能依赖服务调用方遵循正确逻辑。
比方，用户注册的服务，其中蕴含了对于用户邮箱格局、用户名称以及明码强度的校验逻辑，尽管这些逻辑在前台利用的 Web 页面或者 App 中都进行了相干的校验，但前台利用最终调用用户核心的用户注册服务时，仍然要在该服务中实现对这些用户属性的校验工作，而不能寄希望于前台利用做这些校验工作，这样能力防止因为前台利用脱漏校验而导致不合规定的用户能胜利进行注册。一个典型的服务性能内聚的例子如图 4 -13 所示。
3、服务粗粒度
服务的使用者对特定业务流程的理解个别比不上服务中心外部的人，所以服务的接口设计通常须要粗粒度，一个操作有可能对应一个残缺的业务用例或者业务流程，这样既能缩小近程调用次数，又能升高学习老本和耦合度。
例如，文档服务要给前台利用提供批量删除文章的反对，已有接口中提供 deleteArticle(long id）办法，能够供用户本人做循环调用来实现批量删除文章的目标。此时，服务中心最好提供 deleteArticles(Set<Long> ids）办法供前台利用调用，将 N 次近程调用缩小为一次。
再例如，用户下订单的用例，要有一系列操作：
addItem（累计商品）→addTax（计算税）→calculateTotalPrice（计算总价）→ placeOrder（创立订单）
交易中心当然能够将这些服务以单个接口办法的形式提供给前台利用，这样不仅须要前台利用对于订单创立流程和逻辑有更高的要求，而且会减少呈现服务调用谬误的概率，最好封装一个粗粒度的办法供用户做一次性近程调用，同时也暗藏了外部业务的很多复杂性。服务调用方也从依赖 4 个办法变成了依赖 1 个办法，从而大大降低了程序耦合度。
另外，从服务和接口办法的数量角度来看，服务将通常作为测试和公布的单位，如果粒度过粗，将大量操作分组到单个服务中，则可能减少单个服务的使用者，这样就为服务使用者疾速找到正确的操作带来了挑战，从而导致服务应用体验不佳。要更改服务，势必须要从新公布整个服务，从而影响较多使用者。
所以要防止服务粒度的两个极其：
- 提供仅有几个办法的很多服务。
- 数十或数百个操作均集中在几个服务中。
应思考多个因素，如可维护性、可操作性和易用性，并进行折中。
还有一种划分服务粒度的办法是，创立反映业务对象生命周期的状态的服务接口。例如，费用申领中，每笔费用申领的生命周期都蕴含四个状态，如图 4 -14 所示。
因为业务对象状态经常能同时反映业务和技术两方面的内容，因而齐全能够将 ExpenseClaimService（费用申领服务）拆分为适应每个状态的多个服务：ClaimEntryService（费用构建服务）、ClaimApprovalService（费用审批服务）、ClaimPaymentService（费用领取服务），失去如下所示的服务代码：
ClaimEntryService {createClaim(String userId);
ClaimItemDetails[] getClaimItems(int);
ClaimErrors[] validateClaim(int claimId);
void removeClaimItem(int claimId, int itemId);
int addClaimItem(int claimId, ClaimItemDetails details)
int submitClaim(int claimId);
}
ClaimApprovalService {int approveClaimItem(int claimId, int itemId, String comment);
void approveClaim(claimId)
void returnClaim(claimId)
ClaimItemDetails[] getClaimItems(int);
ClaimErrors[] validateClaim(int claimId);
}
ClaimPaymentService {void payClaim(int claimId);
}通过这种形式，能更不便地了解每个服务。而且，将接口这样划分非常适合服务的开发、部署、保护和应用形式。总结来说，通过将划分逻辑放在对象生命周期上，咱们就能够建设具备失当粒度的服务。
4、打消冗余数据
因为服务的近程调用须要网络开销，特地是在并发量很大的场景下，这样的开销就不是一个能够疏忽的因素了。所以在服务的输出参数和返回后果中，要尽量避免携带以后业务场景不须要的冗余字段，来缩小序列化和传输的开销。同时，去掉冗余字段也能够简化接口，防止给内部用户带来不必要的困惑。
比方“文档服务”中有个返回文章列表的办法：
List <Article> getArticles(...)
如果业务需要仅仅是要列出文章的题目，那么在返回的文章对象中就要防止携带它的内容等字段。
这里有一个经典解决方案，就是引入后面提到的 DTO 模式，专门针对前台业务利用定制要传输的数据字段，这里须要增加一个 AriticleSummary（文章概要）的额定数据传输对象：
List<ArticleSummary> getArticleSummaries(...)
ArticleSummary 能很好地防止服务中心与前台利用间的冗余数据传输。
5、通用契约
因为服务不假如用户的范畴，所以个别要反对不同语言和平台的客户端。但各种语言和平台在性能丰富性上有很大差别，这就决定了服务契约必须取常见语言、平台以及序列化形式的最大公约数，能力保障服务具备宽泛兼容性。因而，服务契约中不能有某些语言才具备的高级个性，参数和返回值也必须是被广泛支持的较简略的数据类型（比方不能有对象循环援用）。
例如，原有对象模型如下：
Class Foo {private Pattern regex;}其中，Pattern 是 Java 特有的预编译，可序列化正则表达式（可进步性能），但在没有特定框架反对的状况下，其余开发语言可能辨认不了，所以最好采纳 DTO 的形式改成罕用的数据类型，如下所示：
Class FooDto {private String regex;}6、隔离变动准则
当服务中心外围畛域模型的对象进入前台利用中，要防止服务中心外部的重构或者模型变更导致前台利用也跟着变动。
比方后面形容的“文档服务”，其中 Article 对象在服务中心外部可能作为外围建模的畛域模型，甚至作为对象和数据库映射（O/R mapping）等。如果文档服务给服务消费者间接返回 Article，即便没有后面所说的冗余字段、简单类型等问题，也可能让服务内部用户与服务外部零碎的外围畛域模型产生肯定的关联，甚至可能与 O /R mapping 机制、数据表构造等产生关联，这样一来，外部的重构很可能影响到服务内部的用户。
同样，可采纳外观模式和 DTO 作为中介者和缓冲带，隔离内外零碎，把外部零碎变动对外部的冲击降到最低。
7、契约包装
尽管应用了 DTO 和外观模式将服务生产端的变动与服务生产端进行了隔离，但 DTO 和外观模式可能被服务生产端的程序到处援用，这样生产端程序就较强地耦合在服务契约上了。一旦契约更改，或者生产端要抉择齐全不同的服务提供方（有不同的契约），批改时工作量可能就十分大了。在较现实的面向服务设计中，能够思考包装近程服务拜访逻辑，也称为服务代理（Delegate Service）模式，由生产端本人主导定义接口和参数类型，并将服务调用转发给真正的服务客户端，从而让服务使用者齐全屏蔽服务契约。
服务代理示例如下：
//ArticlesService 是生产端自定义的接口
class ArticlesServiceDelegate implements ArticlesService {
// 假如是某种主动生成的 service 客户端 stub 类
private ArticleFacadeStub stub;
public void deleteArticles(List<Long> ids) {stub.deleteArticles(ids);
}
}在此示例的前台利用中，所有无关文档服务调用的中央援用的都是 ArticlesService，而不是“文档服务”提供的 ArticleFacadeStub，这样就算服务提供端的 ArticleFacadeStub 产生了变更或者重构，也只须要在 ArticlesService 类中进行相应的调整，而无须更改更多的代码。
8、服务无状态准则
为了保障服务中心的服务稳定性以及可扩展性，必须将服务设计为可伸缩的且可部署到高可用的根底构造中。此重要准则的一个推论就是，服务不应为“有状态型”的。即服务不应依赖于服务使用者和服务生产者之间长期存在的关系，服务调用也不应显式或隐式地依赖于前一次调用。为了阐明这一点，咱们举一个简略的例子，上面是一个电话对话：
问：小明的账号余额是多少？
答：320 元。
问：他的信用额度是多少？
答：2000 元。
此示例演示了典型的有状态模式。第二个问题通过应用“他的”援用第一个问题。这个示例中的操作依赖于转换上下文。当初让咱们考虑一下所提供的应答，请留神，答复中没有上下文信息。只有在被询问者晓得所询问的问题时，这个答复才有意义。在此示例中，要求使用者保护对话状态，以便解释所失去的应答。
首先，咱们考虑一下依赖于前一操作建设的上下文的操作。如果这是一个与呼叫核心的交互，只有与同一个操作人员对话，对话就能够无效地完结。但咱们假如呼叫被中断了，如下所示：
问：小明的账号余额是多少?
话务员 1：320 元。
此时通话中断，被转接到另一个话务员：
问：他的信用额度是多少？
话务员 2：谁？
中断导致上下文失落，因而第二个问题是没有意义的。就这个电话对话而言，咱们能够通过从新建设上下文而对消中断带来的结果：“我在问小明的银行账户的信息，您能通知我他的信用额度吗？”不过，在可扩大服务调用畛域，有状态对话通常更为麻烦，从新建设上下文兴许在技术上可行，但很可能带来很大的性能开销。
是否要求应用关联性。即雷同的服务使用者收回的间断申请是否必须交付到雷同的服务提供者实例，要求应用关联性是一种有状态性与可伸缩性及可靠性抵触的状况。为了放弃服务中心各服务能力的服务质量，咱们必须优先思考最终服务架构的可伸缩性和可靠性。所以笔者强烈建议，将服务设计为可防止保护会话上下文的需要。
回到下面电话对话的示例，咱们能够通过将服务设计为在响应中蕴含适合的关联信息，从而防止对会话状态的需要，如下所示：
问：小明的信用额度是多少?
答：小明的信用额度是 2000 元。
在响应中蕴含关联信息是很好的做法，起因很多。首先，它简化了可伸缩解决方案的结构，还能提供更多的诊断帮忙，且在不可能向原始申请程序交付谬误响应时十分重要。总之，认真地进行服务设计能够防止对状态的需要，从而简化牢靠的、可伸缩服务构造的实现。
9、服务命名准则
咱们在抉择服务、操作、数据类型和参数的名称时有一个领导准则：心愿最大化服务的易用性。咱们心愿帮忙业务利用开发人员标识实现业务流程所需的服务和操作，因而，强烈建议对服务使用者定义业余畛域内有意义的名称，优先选用业务概念而不是技术概念。
倡议就是：应应用名词对服务进行命名，应用动词对操作进行命名。例如，以下是应用动词短语和 IT 结构的服务定义：
ManageCustomerData {insertCustomerRecord();
updateCustomerRecord();
//etc ... }接下来是应用名词和动词短语及业务概念的服务定义：
CustomerService {createNewCustomer();
changeCustomerAddress();
correctCustomerAddress();
// etc ... }比拟显著，第二个示例的易用性更好一些。在第二个示例中，服务的业务用处十分分明，而不仅仅批示其输入。因而，倡议不要应用“update-CustomerRecord”（能够为出于任何起因进行的任何更新），而应用“enable-OverdraftFacility（启用透支能力）”。与此相似，在客户搬迁时，咱们应用“changeCustomerAddress”办法更改客户地址；而在心愿更正有效数据时应用“correctCustomerAddress”更正客户地址，因为这样很容易看出这两个操作采纳了不同的服务逻辑。
10、服务操作设计准则
这是对于服务操作命名设计准则的进一步深入：该当应用具体的业务含意而不是泛型操作对操作进行定义。例如，不要应用泛泛的 update-CustomerDetails 操作，而要创立 changeCustomerAddress、recordCustomer-Marriage 和 addAlternativeCustomerContactNumber 之类的操作。此办法具备以下益处：
- 操作与具体业务场景对应。此类场景可能不仅是简略地更新数据库中的记录。例如，更改地址或婚姻状况可能须要更改其余业务模块中的相干信息，比方婚姻状况的批改可能会引起会员权利的扭转。如果应用不太具体的操作（如 UpdateCustomerDetails），则不适宜实现此类业务场景。
- 各个操作接口将非常简单，且易于了解，从而进步易用性。
- 每个操作的更新单元有分明的定义（在咱们的示例中为地址、婚姻状况和电话号码）。在实现具备高并发性要求的零碎时，咱们能够基于操作的要求采纳更细粒度的锁定策略，从而缩小资源争用。
针对操作中参数的设计，应采纳粗粒度和灵活性强的参数，目标是尽量减少因为需要变更带来的参数构造变动。
以 CreateNewCustomer 操作的两个接口为例。
- 采纳细粒度参数的 CreateNewCustomer 操作接口如下：
int CreateNewCustomer(String familyName,String givenName,
String initials, int age,String address1,
String address2, String postcode // ... )- 采纳单个粗粒度参数的 CreateNewCustomer 操作接口如下：
int CreateNewCustomer(CustomerDetails newDetails)以上两段示例代码显示了一个具备很多细粒度参数的操作和采纳结构化类型作为单个粗粒度参数的操作。之所以倡议应用粗粒度参数，是因为这样可能在很大水平上防止因为细粒度参数变动带来服务整体版本升级。
从参数灵活性的角度看，要思考服务需要的多样性和灵活性。比方，在查问商品信息时，商品定义的字段很多，不同的业务关注的字段不一样，所以在定义接口时，可通过传入业务方须要返回的商品的字段，将这些字段保留在 List 对象中，服务获取对应字段的值后封装成对应的 Map 对象返回。这样通过一个商品查问的操作方法就能满足不同利用系统对商品字段的信息获取需要。
11、重要的服务不能依赖非重要的服务
中台建设是以服务为核心，即整个体系间的交互均以服务的模式进行。不仅前台利用和中台的各服务中心会以服务的形式进行交互，而且各服务中心之间也会这样交互。在有些状况下，前台利用在业务复杂度倒退到肯定水平后，也会建设起在该利用零碎外部的服务体系。比方，天猫和淘宝这样的业务前端利用曾经非常复杂，其外部就构建起了一个多层的服务体系。业务中台的各服务中心为这个服务体系的最上层，之上的各前端业务零碎中又会依照本身业务的特点建设起本人的服务层级。
在整个服务体系中，有交易、商品、订单相干等这一类十分外围和重要的服务，也有绝对不重要的服务，如运费计算或者前端利用中所创立的服务。从服务对业务的影响水平、服务范畴就会体现出服务重要性不同，而且服务重要性的不同也间接决定了能失去的反对和保障资源会有差别，从而最终会体现在服务的稳固和可靠性方面。所以越在上层的服务会越稳固，越往下层的服务则不论是稳定性还是业务兼容性方面都不如上层服务。
“重要的服务不能依赖非重要的服务”这一准则能够更加细化，如下所示：
- 上可依赖下。越下层的服务实现能够依赖上层的服务，也可跨级依赖。
- 下不可依赖上。上层的服务实现和运行肯定不能依赖下层的服务，否则就会呈现因为下层服务质量问题和不稳固的体现影响到上层的重要服务，而上层服务的故障将会影响到依赖这一服务的所有平级服务中心和前台利用的状况，会呈现重大的“雪崩”效应。
- 平级可依赖，防止循环依赖。这一准则最典型的体现是业务中台的各服务中心在服务层级中均属于平级，它们均有同级别的服务经营要求，是能够相互依赖的。
- 高级别不可依赖低级别。业务重要性显著高的服务不能依赖业务重要性低的服务，应做好相应的服务降级，或者通过前台业务隔离这种状况的服务依赖。
总结
简略就是美，过多的准则可能会让整体的设计变得臃肿，在什么状况下采纳什么样的准则，须要建设在对业务了解的根底上，而且须要在实际过程中一直练习，从而能更从容地应答服务设计相干的问题。
起源：技术琐话
作者：钟华
本文由机械工业出版社独家受权公布，中台圣经——《企业 IT 架构转型之道》作者钟华新作！《数字化转型的道与术：以平台思维为外围撑持企业策略可继续倒退》。
申明：文章取得作者受权在 IDCF 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。
6 月每周四晚 8 点，【冬哥有话说】开心一“夏”。公众号留言“开心”可获取地址
- 0603 无敌哥《IDCF 人才成长地图与 5P》（《端到端 DevOps 继续交付 (5P) 精品课》第 1 课）
- 0610 冬哥《带你玩转翻新设计思维》
- 0617 无敌哥《麻利项目管理到底是个啥》
- 0624 冬哥《VUCA 时代的麻利领导力》
