开发者学堂课程【高校精品课-上海交通大学-企业级应用体系架构：Hadoop 1】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/75/detail/15841
Hadoop 1（一）
内容介绍
一．认识 SOA
二．如何组装服务
三．服务和构建的区别
四．服务的架构
五．微服务
六．SOA 的架构
七．Hadoop,Spark 和Storm
一．认识 SOA
1.SOA 要解决什么问题
SOA 就是面向服务的架构，他要解决的是什么问题呢？在实际的 IT 这个应用的开发过程当中，你会遇到什么问题呢？
一方面我们希望要削减预算、降低成本，另一方面用户要求你对他们的需求快速的响应。你肯定就要最大限度地去复用现有的这些资源，现有的这些资源在复用的时候，就碰上两个问题。第一个就是所有的系统，我想去复用，但是这些系统可能是异构的，比如学校里面会有 OA 的系统，有学生教务处管理的系统，有交费的系统等等。
那这些系统有可能是不同的语言开发的，使用的数据库也不一样，操作系统也不一样，这个问题要怎么解决呢？
第二个问题就是，用户的需求在不断发生变化，导致你在不断的进行系统的修改，应该怎么去应对这个变化？
为了解决这个问题，我们前面讲的 web service ，确实一直在面对异构性，但是变化怎么办？变化意味着你的代码互相之间，这些 service 之间需要结偶。也就是说，没有一定和哪个服务绑定，要结偶。
那如何做到结偶呢？我们前面讲到通过消息的机制来实现结偶，这就是我们可以借鉴的方式，在我们讲消息的时候，我们说里面用的是 GMS ，在 Java 的平台上是这样做的。如果我利用消息中间件，传递的不是 Java 的消息，而是像上节课，我们讲的 web service 里面的这些 SOAP 消息，或者是 restful 这些数据驱动的纯数据。那么，一方面可以实现服务和服务之间的结偶，另外一方面，由于结耦，我传递过去的数据本身，我对他们没有什么太多要求，只要求都是某一种文本格式描述，我要解决异构性。所以基于这个考虑， SOA 这个架构就说，我们要应对这种易构性的系统之间的互操作性，以及不断的变化的需求，所以我们要考虑：首先平台里面都要是一些服务，上节课我讲到 web 服务里面的服务是讲独立与实现，也就是说，任何一种语言都能去实现，像上节课一样， Java 的服务可以和 domact 的客户端之间通信，反过来也是这样的。这是因为它们都是在走纯文本的这种 SOAP 消息，或者是像 restful 里走 Json 消息，不管怎么样，他们传递的是纯文本的东西。我们要借鉴消息中间件的这种机制，要去让服务和服务之间松散耦合，那么还有一个问题就是，要想做到松散耦合，消息中间件就是有消息的发送者，有消息的接收者在这边做消息的接收，它俩互相之间不知道对方是谁。消息的发送者会把消息发到消息中间件里面的某一个 Qwewe 或者是 Topic 里面，但它并不知道消息是被谁给拿走的，它只知道我要做这件事，即往这个 Topic 或者 Qwewe 里面去发送一个消息，所以到底是谁把它拿走这件事情， send 是不知道。所以它就可以支持位置透明，不需要知道对方在哪里，只和这个消息中间件打交道。然后，我们上节课讲 web 服务的时候讲到了使用 web 的协议，虽然我们经常用的是 HTTP ，但也可能会有 FTP，SMTP， 简单邮件传输协议，文件传输协议，小文件传输协议，SFTP 等等，这些都是 web 上的协议。如果一个服务是 FTP 协议通信的，当它发送走的时候，对方是一个 HTTP 协议的接收，这时候应该怎么办呢？
2.消息中间件
其实消息中间件就可以做这样的事情，它就像一个邮局，当你发给我一个，比如用中国的标准信封包装的一个信的时候，我为了让对方能接收到，我可以把它拆开，或者对它再进行一次封装，把它放到一个美国的标准信封里。这样的话，对方如果是按照美国的邮箱，标准的信封进行收件的，那他就可以拿到这个数据。也就是说，这个消息中间件要做一次协议的转换，所以他可以告诉你任何一个服务，不管用什么协议进行通信，它都可以被其他的协议调用。
所以只要满足这三个条件，我们就能够去应对异构性或者需求的变化这样的场面，即松散耦合，服务和服务之间不直接交互，它们的位置透明，我不需要知道对方在哪里，也不需要跟对方保持一样的协议。
这三个特性都是靠着中间件来完成，显然，它比之前讲的消息中间件要复杂一点，比如它包括了一个比较复杂的路由和一个协议转换这样的功能，这种东西就被称为服务总线。这就是（ service “bus”）服务总线，它采用了三个特性之后给我们带来的一个特性，这三个特性就是面向服务的架构，是特有的，它是靠消息中间件为基础的这种服务总线来实现。
3.SOA 和 web 服务
现在有一个问题，如果我有一个应用，我把它里面所有的功能全部包装成 web 服务，那么这时候它是不是一个 SOA 架构？很显然， SOA 和把所有的服务包装成 web 服务是两个概念， SOA 是要满足这三个特性的，所以，如果在你的应用里面，你把所有的功能全包成 web 服务，也不代表它是个 SOA 架构。只是说可以通过 web 服务的方式去访问到它，最多能满足异构的系统可以调用，但是未必是松散耦合的，那么位置未必是透明的，我还是要知道 web 服务在哪里，还是要知道你应该怎么去调用，还是按照你的协议去调用。只能说在 SOA 的世界里，虽然看到的都是服务，这些服务是松散耦合，通过 web 服务的总线继承下来，也就是他们的交互方式，就像我们前面说的，以消息中间件为核心、以一个异构通信的方式为主的方式来进行交互，但是不代表这个服务必须要是 web服务。意思就是我不一定要是 web 服务，还可以是其他类型的服务，比如 Java 的微服务。所以 SOA 里面说它要满足这三个条件，必须要有服务总线，但是它的服务未必非要是 web 服务，而把一个系统里所有的服务功能全部包装成 web 服务，不代表它就是 SOA 。只能说你的系统能够被异构的客户端访问到，但这些服务之间，比如它是紧耦合的，它们互相之间必须要知道对方的位置在哪，位置一旦发生变化，代码就要修改。那么它们都要采用相同的这个协议，所以它们之间不是这样直接对等的，它们看问题的方式不一样。这种 SOA 架构要实现的功能到底是什么样？达到的特定是什么？就是这里讲的这三点特性，如果达不到这三点特性，就不能说它是一个 SOA 系统。所以我们说只把所有功能包成 web service ，它离 SOA 也还差一段距离。
二．如何组装服务
那么这个服务是怎么组装出来的呢？在大二的时候，我们说你眼里看到的是一个一个的对象，设计的是类，也就是说我们在进入这个专业，你在学习的时候，我们反复强调的一个词就是复用。你的大一的时候，你知道的是我要定义一些变量，这些变量在未来可以进行复用，也就是我把值放到变量里，未来可以再读取它里面的内容再做处理。然后就看到了，还有一些重复的代码，我想给它剔除，定义成一个一个的函数。然后，在程序设计里面，后来讲到我们要对若干个函数和它的状态碰撞产生类，我们要从这个类里创建出来一系列的对象，这些对象就在复用这个类的代码。那大二的时候，我们强调要出现的 Component 即构建。也就是说，如果你把类看成是砖头，那么构建实际上就是用砖头垒起来的墙，或者是水泥构建的一个预制板。就是若干个类合起来实现了一个比较独立的功能的时候，这些东西合起来就是一个构件，比如最简单的，我们在前端的页面里面可能有选日历的、选日期的这样的功能，那这个日历的 JS 的小控件就是一个构建，它里面可能不止一个 Java 的类，还要有按钮，要选日期，然后把日期只读进去，会有若干个 Java script 的类。这些东西合起来才能完成一个功能，把它单独拆开来去看是没有意义的。所以，他们合起来作为一个更大力度的一个封装，一个适用的视频，那就是一个 component 。我们再来看服务是什么。我们的服务确实是在现有的代码上分装出来的，比如上节课，我们给大家举了一个例子，就是一些 Java 的接口把它封装成了服务，让这些服务可以用 SOAP 方式或者 restful 的方式被访问到。
三．服务和构建的区别
那么，服务是不是构建力度上更大力度的一个分装呢？是不是若干构建合在一起叫一个暴露出去这样一个服务呢？我们看到的很多图都是这样画的，它的概念看起来就像是服务，是在构建的基础上再做一次分装，但是它和构建和类之间的关系不太一样，构建和类的关系确实是若干的类封装出一个构件，但是从服务的角度看，不是若干个构建分装出一个服务。确切的说，服务这个词更面向于用户，他更面向于需求的这样的一个描述，或者我们理解为它是更和业务逻辑相关的一个东西，所以它是从业务的角度去划分服务。而构建纯粹是你在编程的时候，比如面向对象的分析设计，或者面向对象编程的时候，你从代码复用的角度去抽象出的一个可复用的东西，他俩之间没有说是一对一的映射，可能一个构建可以封装出两个服务，然后一个服务是对两个构建的一个封装，没有说它的力度一定比较粗，只是说他们面向的方向不一样。比如这是一个日历 cal 的一个构建，那这个可能是一个，例如用户注册的一个构建，就是它会有检查用户名等等。那你上面的服务会有什么呢？比如会有管理员注册、会有一般的用户注册，会有两个服务，那它们两个要求的内容不一样，管理员的可能会多一点，但是它们两个里面都会包含这样的构建。所以，服务和构建之间，其实不是谁的例子比谁大的问题，而是它们两个面向的东西不一样，一个面向的是业务逻辑，一个面向的是编程角度。它们两个的映射之间，实际上是哪个更多的关系，这是我们对服务的一个看法。
