初识微服务架构，Docker技术初体验

一.我眼中的《系统综合实践》

　　以鄙人之拙见，《系统综合实践》是一门讲解如何由软硬件搭建各种系统、利用系统进行科学地研究的课程，形式上主要通过实践的方式让我们了解各种系统的特点、工作原理、运行方式等，对拓

展我们的知识域很有帮助，是一门很有意义的技术课程(其实开课之前我一直以为这是系统结构的配套实验来着hhh~)。

　　说说对这门课的亿点点小期待吧！首先呢，希望自己在这门课中可以学到一些有用的知识(当然了，如果有奇怪的知识也能欣然吸收~)、掌握一些基本实用的技术或者技能，最好能够学以致用，应

用到实际开发中；其次呢，就是希望这门课不会陷入一般实践课的泥潭————过于枯燥，建议以比较具有趣味性的授课形式(一脸坏笑.jpg)进行教学，不仅活跃了课堂气氛，还顺带让我们在放松的环境

下轻松学习，一举两得，岂不美哉！Last but not least，自从经历了上学期的软工实践，我深刻感受到了实践的魅力~~真相是熬夜的痛苦~~，开始对实践课产生了敬畏之心(毕竟熬过的半个学期的

夜还是挺刻骨的)，所以衷心祈祷这门课友好一点，不要演变成软工的进阶版本了~~发量快撑不住了QAQ~~(🏀🏀🙏)！！！

二.初识微服务架构

（1）什么是微服务架构

　　微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多

SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。

本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

（2）特点和标准

特点：

1、一些列的独立的服务共同组成系统

2、单独部署，跑在自己的进程中

3、每个服务为独立的业务开发

4、分布式管理

5、非常强调隔离性

大概的标准：

1、分布式服务组成的系统

2、按照业务，而不是技术来划分组织

3、做有生命的产品而不是项目

4、强服务个体和弱通信（ Smart endpoints and dumb pipes ）

5、自动化运维（ DevOps ）

6、高度容错性

7、快速演化和迭代

(3）传统软件模式与微服务的区别

　　先来看看传统的web开发方式，通过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的，这种方式一般被称为Monolithic（单体式开发）。

所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。

优点：

①开发简单，集中式管理

②基本不会重复开发

③功能都在本地，没有分布式的管理和调用消耗

缺点：

1、效率低：开发都在同一个项目改代码，相互等待，冲突不断

2、维护难：代码功功能耦合在一起，新人不知道何从下手

3、不灵活：构建时间长，任何小修改都要重构整个项目，耗时

4、稳定性差：一个微小的问题，都可能导致整个应用挂掉

5、扩展性不够：无法满足高并发下的业务需求

（4）微服务与SOA的区别

1、SOA喜欢重用，微服务喜欢重写

SOA的主要目的是为了企业各个系统更加容易地融合在一起。说到SOA不得不说ESB(EnterpriseService Bus)。 ESB是什么? 可以把ESB想象成一个连接所有企业级服务的脚手架。

通过service broker，它可以把不同数据格式或模型转成canonical格式，把XML的输入转成CSV传给legacy服务，把SOAP 1.1服务转成 SOAP 1.2等等。它还可以把一个服务

路由到另一个服务上，也可以集中化管理业务逻辑，规则和验证等等。它还有一个重要功能是消息队列和事件驱动的消息传递，比如把JMS服务转化成SOAP协议。各服务间可能有

复杂的依赖关系。

微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始，

把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然后单独布署。它通常不依赖其他服务。微服务中常用的API Gateway的模式主要目的也不是重用代码，

而是减少客户端和服务间的往来。API gateway模式不等同与Facade模式，我们可以使用如future之类的调用，甚至返回不完整数据。

2、SOA喜欢水平服务，微服务喜欢垂直服务

SOA设计喜欢给服务分层(如Service Layers模式)。我们常常见到一个Entity服务层的设计，美其名曰Data Access Layer。这种设计要求所有的服务都通过这个Entity服务层

来获取数据。这种设计非常不灵活，比如每次数据层的改动都可能影响到所有业务层的服务。而每个微服务通常有它自己独立的data store。我们在拆分数据库时可以适当的做些

去范式化(denormalization)，让它不需要依赖其他服务的数据。

微服务通常是直接面对用户的，每个微服务通常直接为用户提供某个功能。类似的功能可能针对手机有一个服务，针对机顶盒是另外一个服务。在SOA设计模式中这种情况通常会用到

Multi-ChannelEndpoint的模式返回一个大而全的结果兼顾到所有的客户端的需求。

3、SOA喜欢自上而下，微服务喜欢自下而上

SOA架构在设计开始时会先定义好服务合同(service contract)。它喜欢集中管理所有的服务，包括集中管理业务逻辑，数据，流程，schema，等等。它使用Enterprise

Inventory和Service Composition等方法来集中管理服务。SOA架构通常会预先把每个模块服务接口都定义好。模块系统间的通讯必须遵守这些接口，各服务是针对他们的调用者。

SOA架构适用于TOGAF之类的架构方法论。

微服务则敏捷得多。只要用户用得到，就先把这个服务挖出来。然后针对性的，快速确认业务需求，快速开发迭代。

（5）微服务的部署

详见如何部署微服务

三.docker技术初体验

（1）docker是什么？

　　Docker 是一个开源项目，诞生于 2013 年初，最初是 dotCloud 公司内部的一个业余项目。它基于 Google 公司推出的 Go 语言实现。项目后来加入了 Linux 基金会，遵从了 Apache 2.0
协议，项目代码在GitHub 上进行维护。
　　Docker 项目的目标是实现轻量级的操作系统虚拟化解决方案。Docker 的基础是 Linux 容器（LXC）等技术。在 LXC 的基础上 Docker 进行了进一步的封装，让用户不需要去关心容器的管
理，使得操作更为简便。用户操作 Docker 的容器就像操作一个快速轻量级的虚拟机一样简单。

　　通过下面两幅图片可以阐述传统虚拟化方式和docker运行方式的差异，docker是在操作系统层面上实现虚拟化，直接复用本地主机的操作系统，而传统方式则是在硬件层面实现。

（2）docker镜像和容器

　　镜像

　　镜像（Image）就是一堆只读层（read-only layer）的统一视角，如下图：

　　从左边我们看到了多个只读层，它们重叠在一起。除了最下面一层，其它层都会有一个指针指向下一层。这些层是Docker内部的实现细节，并且能够在主机（译者注：运行Docker的机器）的文件

系统上访问到。统一文件系统（union file system）技术能够将不同的层整合成一个文件系统，为这些层提供了一个统一的视角，这样就隐藏了多层的存在，在用户的角度看来，只存在一个文件系

统。我们可以在图片的右边看到这个视角的形式。

　　容器
　　容器（container）的定义和镜像（image）几乎一模一样，也是一堆层的统一视角，唯一区别在于容器的最上面那一层是可读可写的。

　　要点：容器 = 镜像 + 读写层。并且容器的定义并没有提及是否要运行容器。

（3）docker环境搭建

系统环境

虚拟机：VirtualBox
　　操作系统：Ubuntu 16.04 LTS（其他版本也可以）
docker安装

　　参考教程Ubuntu Docker安装进行安装，安装成功后，执行指令"sudo docker run hello-world"，出现如下信息，说明安装成功：

pull镜像

　　1）使用格式为：docker pull [OPTIONS] NAME[:TAG|@DIGEST]（若省略[:TAG|@DIGEST]，则默认pull最新版本的镜像）从公共仓库pull一个镜像，例：

　　ps：若pull过程速度很慢，建议使用阿里云镜像进行加速，具体可参考docker pull很慢解决办法