第1章：服务化介绍 和 快速入门

第1章：服务化介绍 和 快速入门
1.简介
当我们使用java语言来编写代码时，通常是以面向对象的视角来把现实中的事物抽象到java程序中的类对象来表现，类对象里封装了该对象特有的属性和行为，这类编程方式能让我们更好的把现实中的事物转化为计算机程序来表示。那为何还要存在面向服务呢？
面向对象是一种细粒度的把现实事物转化为计算机程序，在这个转换过程中会引入许多的设计模式和设计原则。比如一个UserService.login的登录功能，它具有以下逻辑：

图1-1

假设我们在以面向对象方式去实现这个功能时，我们会：
1.验证方法通过实现一个validate方法
2.查询用户调用一个UserDAO.findByUser();
3.判断返回的User是否为null和User.state状态是否正常
4.调用SMSUtil.sendSMS() 发送短信;
5.调用NotifyService.notify()通知好友
6.调用Log.info(“…”);

我们可以通过一些设计模式把这个login方法写的很灵活，比如这里把各个流程都拆开来由不同的方法来实现。然后通过组合这些流程来达到代码的复用。
面向服务架构其实和这个面向对象很相似，面向服务架构最基本的组成单元是服务，这个服务的概念和上面提到的流程所实现的方法一样，只是“服务”在这个“流程方法”之上完善了一套更加符合这种以复用业务流程为目的的设计范式，而且服务可根据业务领域来规划边界单独部署集群来提升系统的伸缩性和自治性。

图1-2

原子服务（实体服务、业务服务）：原子服务指的是围绕自身实体对象而展开的行为，不跨越其他实体对象。比如图1-2的原子服务里的User实体原子服务，最常见的就是CRUD了。
组合服务：对原子服务进行组合成一个新的服务即是组合服务。对于该类服务可以通过业务领域对其进行划分，如“用户”领域。组合服务不能跨业务领域组合其他业务领域的原子服务，只能组合自身业务领域的原子服务和工具服务。尽量做到服务领域内聚，才能提高服务的自治性。
流程服务：流程服务指的是对跨领域边界的服务“组合”后所形成的一种服务，而且流程服务又能作为子流程服务被上层流程服务所调用。即图1-2的login流程服务可以被各类系统的表现层（控制器、UI服务）所调用，如IM系统，游戏系统，CRM系统等。
工具服务（基础设施服务）：这类服务主要是指非业务相关的服务，无耦合任何业务状态。如：DB，Cache，MQ，日志，SMS短信
服务编排：服务编排通常指的是对于服务的交互流程经常随着公司的战略来调整，比如跨部门、跨公司、跨业务大类的流程交互的组合，编排的服务可以是任意服务，不过通常是流程服务和组合服务。这类服务需要引入服务编排语言，在流程改变需要改变的时候可以动态调整。

接着看看京东的服务化架构图，是如何重用服务的~！

图1-3

图1-4

图1-5

通过图1-3可以看到业务层之下是“服务层”和“基本应用层”，这个服务层可以认为 流程服务、组合服务、原子服务被抽象为共存的一个层（物理上并不共存）。而基本应用层则是根据业务领域边界划分的一个个原子服务+组合服务。如商品中心、订单中心..各个领域内的服务都在物理上进行隔离，且业务领域内聚，使其自治性达到最大化。
而业务层则是各个系统，通过复用下面的 服务层来完成服务化。
假设现在基本应用层存在一个“用户中心”，在服务层通过流程编排完成图1-1的服务，此时该服务可被业务层的各个系统所复用。如：订单系统，用户复用该服务登录查看相关订单。
商品系统，商家登录管理自己的商品架。

服务化中最重要的是 服务治理！！
如何确保服务在IT企业的服务仓库中是唯一的服务（不冗余）？
如何确保服务在IT企业的服务仓库中的 “重用性”？
如何确保服务在IT企业的服务化中有一致性的实施方案，如接口定义，数据模型一致性。

2.面向服务目标和价值

正如前面所提到过的“面向服务”架构是一套在“面向对象”基础上以一种IT企业战略角度上来完善 “逻辑单元” 的复用性。

1.互操作性的提供，即服务之间可以根据业务需求来组合调用
2.增强： 保持服务自身独立的自治性和自主管理。
3.屏蔽技术间的差异，通过数据模型
4.业务和技术领域一致性的提高，对服务进行多层次的抽象，一个最有效的方法是建立一个精确封装和表达业务模型的服务层次。由业务专家亲自动手参与，精确定义概念性的服务候选，由此得到的服务设计有能力保持自动化技术和业务职能的一致性。
5.投资回报率的提高， 服务复用。减少开发成本、维护成本
6.组织敏捷度的提供：对于公司的业务变更能快速的做出技术响应。

3.服务组织架构

服务仓库（服务库存）：服务仓库指的是把企业的所有服务（战略目标）划分到一个仓库里管理，这个仓库也许是物理上抽象的。通过服务仓库，我们能清楚的得知企业当前所拥有的服务情况，通过建立服务仓库来管理企业的战略目标。

服务：服务是作为逻辑单元的存在，也是面向服务架构中最基本的组成单元。

服务合约：通过建立形式化或者标准化的合约，并遵循使用。合约能使我们更好的规范企业的SOA部署，对整体企业各个部门的SOA起到了规范作用，方便企业SOA更好的建立和管理维护。

领域专家（业务专家）：通过和业务专家沟通，得知企业目前的业务状况，业务细节以及业务发展的愿景。

服务分析员：通过和领域专家沟通，把企业的业务需求转换为“服务”。服务分析员需要擅长沟通、服务设计，然后引导领域专家清晰的表达业务细节，再把业务细节都转化为具体的服务划入服务仓库蓝图中。

服务架构师：服务架构师主要负责把服务仓库蓝图中的 预定义服务转化为 服务仓库中的服务，和设计服务合约，服务架构设计等。

服务管理者：服务管理者主要负责 服务仓库中的服务管理，如服务的概要文档，服务版本管理，服务的扩展修改等。
4.技术架构
5.SOA服务应用开发流程
服务应用开发流程又分为2种，一开始的自顶向下设计，和自底向上设计。
自顶向下设计：自顶向下指的是一开始则建立服务仓库蓝图，通过分析业务领域的详细情况，把业务转化为蓝图中的预服务（正式服务的候选者），最后再通过服务设计原则把蓝图中的服务转化为实际 服务仓库中的服务。
自底向上设计：把迫切实现业务的需求作为优先的目标，不会详细去考虑将来服务的变更，服务与服务间的关系（现在及将来）。
自底向上可以快速的交付服务，但是可能给将来的服务治理带来更大的维护成本（时间，人力）。而自顶向下则与之相反。
这里主要讲自顶向下设计：
一：建立服务仓库蓝图
1）服务分析员通过和领域专家沟通定义企业的业务模型，业务模型需要能精确表达非封装业务逻辑。
2）服务架构师和技术架构师共同定制服务的技术架构，如服务的功能合约，技术合约，设计原则等，通过技术架构来限定业务模型进入服务仓库蓝图中。
3）定义服务仓库蓝图。服务仓库蓝图就好比如草稿，通过不断的修订草稿，最终成为正式的文档。在这里也一样，通过不断的优化蓝图中的服务，最终把蓝图中的服务转换为正式的服务仓库中的成员。这一步需要确认服务的领域边界及服务的类型，是属于组合服务还是实体服务。
二：建立正式的服务仓库
1）完善每个服务的服务概要，指的是服务的元信息。通过元信息能清楚了解到当前服务的领域边界，服务模型，服务的功能描述，服务的接口信息，输入输出参数描述等。
2）建立服务仓库的维护方针。如服务仓库中的服务CRUD，元信息的规范等
三：开发服务逻辑
1）建立服务的技术架构体系。如根据服务的领域边界，建立服务的分模块项目开发
2）首先完善服务的基本设施服务
3）编写实体服务和组合服务
4）编制流程服务

6.搭建你的第一个服务