入门、快速搭建Docker分布式项目环境？如何快速地搭建起社群

本文目录

• 入门、快速搭建Docker分布式项目环境
• 如何快速地搭建起社群
• 如何快速搭建一个微服务架构

入门、快速搭建Docker分布式项目环境

1.什么是Docker

借用下网上传统虚拟机与Docker的对比图片。

传统虚拟化应用程序中，不仅包含应用程序和必要的二进制文件库，还包含一个完整的操作系统。

而Docker容器仅包含应用程序和相关依赖项，在主机的操作系统用户空间中作为一个独立进程运行，与其他容器共享内核，从而实现了虚拟机的资源隔离和分配，具有更高的可移植性和效率提高。

2.为什么使用Docker

1.更快速的交付和部署

开发者可以使用一个标准的镜像来构建一套开发容器，开发完成之后，运维人员可以直接 使用这个容器来部署代码。

2.高效部署和扩容

Docker 容器几乎可以在任意的平台上运行，包括物理机、虚拟机、公有云、私有云、个人电脑、服务器等。

3.更高的资源利用率

Docker 对系统资源的利用率很高，一台主机上可以同时运行数千个 Docker 容器。容器除了运行其中应用外，基本不消耗额外的系统资源，使得应用的性能很高，同时系统的开销尽量小。传统虚拟机方式运行 10 个不同的应用就要起 10 个虚拟机，而Docker 只需要启动 10 个隔离的应用即可。

4.更简单的管理

使用 Docker，只需要小小的修改，就可以替代以往大量的更新工作。所有的修改都以增量的方式被分发和更新，从而实现自动化并且高效的管理。

3.Docker的工作原理和概念

自己制作镜像然后上传仓库或使用仓库已有的镜像文件拉取到容器中部署。

为了方便Docker的说明，本次例子使用虚拟机安装CentOS 7来演示。CentOS 7的安装请等查看下篇文章或自行百度。

1.安装之前的准备工作

按照顺序，执行如下操作

1、安装必要的一些系统工具

2、添加软件源信息

3、更新并安装Docker-CE

安装准备工作

2.开启Docker服务

运行docker version 如果出现以下情况，说明当前用户没有 root相关操作权限

无root权限

解决思路

先查看有多少镜像

运行docker run hello-world 测试命令，如果出现下方红框内消息，证明安装成功

3.查看docker基本信息和版本

1.构建Nginx基础镜像

查询nginx镜像

镜像拉取

查看对外的访问路径

怎么才能访问刚才启用的nginx

nginx页面内容

我们可以进入容器，看下这个容器是什么样子

查看nginx在哪个位置

我们发现尽管启动了nginx，但是在外部还是不能访问，这是因为docker具有隔离机制，要不然怎么叫做容器化部署呢

Docker内nginx端口

对Nginx进行外网端口映射；

2.构建Tomcat基础镜像

打开容器后，默认安装目录在 /usr/local/

3.创建自己的专属镜像

用Dockerfile来制作镜像

创建一个新的镜像，并起名字为nywlw

查看新的镜像

运行自己创建的容器

4.删除容器实例

5.删除镜像

每天发布更多新鲜有含量的技术文章、总有一款适合你。

如何快速地搭建起社群

一、社群运营的定位

采用5W1H

Why——为什么你要建立社群？

What——这个社群带来的价值？

Where——在哪里建社群？

Who——社群里面应该有哪些人？

When——什么时候开始建?计划运营多久？

How——你准备怎么变现？

二、拉群

1、取个社群名称，比如：XX社群运营学习交流群

2、建议每个群的人数控制在50人左右

3、群结构：群主+管理员（2个）+客服（前期3~5人的小团队）

三、社群运营（统一模板，按实际情况转发）

1、定好群公告或者制度

2、互粉模板

3、流程

4、引流软文

5、做好内容输出（问候语、正能量段子、干货分享等）

四、粉丝导流

1、群主将有收费或者消费的粉丝导入学习群

2、学习群将统一学习，为社群的建立打好基础

如何快速搭建一个微服务架构

什么是微服务？

微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务的概念源于2014年3月Martin Fowler所写的文章“Microservices” martinfowler.com/articles/mi…

单体架构(Monolithic Architecture )

企业级的应用一般都会面临各种各样的业务需求，而常见的方式是把大量功能堆积到同一个单体架构中去。比如：常见的ERP、CRM等系统都以单体架构的方式运行，同时由于提供了大量的业务功能，随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得越来越困难。

这种架构模式就是把应用整体打包部署，具体的样式依赖本身应用采用的语言，如果采用java语言，自然你会打包成war包，部署在Tomcat或者Jetty这样的应用服务器上，如果你使用spring boot还可以打包成jar包部署。其他还有Rails和Node.js应用以目录层次的形式打包

上图：单体架构

大部分企业通过SOA来解决上述问题，SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去。因此基于SOA架构的应用可以理解为一批服务的组合。SOA带来的问题是，引入了大量的服务、消息格式定义和规范。

多数情况下，SOA的服务直接相互独立，但是部署在同一个运行环境中（类似于一个Tomcat实例下，运行了很多web应用）。和单体架构类似，随着业务功能的增多SOA的服务会变得越来越复杂，本质上看没有因为使用SOA而变的更好。图1，是一个包含多种服务的在线零售网站，所有的服务部署在一个运行环境中，是一个典型的单体架构。

单体架构的应用一般有以下特点：

微服务架构（Microservices Architecture）

微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖。不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。简单的来说，一个系统的不同模块转变成不同的服务！而且服务可以使用不同的技术加以实现！

上图：微服务架构

微服务设计

那我们在微服务中应该怎样设计呢。以下是微服务的设计指南：

微服务消息

在单体架构中，不同功能之间通信通过方法调用，或者跨语言通信。SOA降低了这种语言直接的耦合度，采用基于SOAP协议的web服务。这种web服务的功能和消息体定义都十分复杂，微服务需要更轻量的机制。

同步消息 REST

同步消息就是客户端需要保持等待，直到服务器返回应答。REST是微服务中默认的同步消息方式，它提供了基于HTTP协议和资源API风格的简单消息格式，多数微服务都采用这种方式（每个功能代表了一个资源和对应的操作）

异步消息 – AMQP, STOMP, MQTT

异步消息就是客户端不需要一直等待服务应答，有应到后会得到通知。某些微服务需要用到异步消息，一般采用AMQP, STOMP, MQTT 这三种通讯协议

消息格式 – JSON, XML, Thrift, ProtoBuf, Avro

消息格式是微服务中另外一个很重要的因素。SOA的web服务一般采用文本消息，基于复杂的消息格式（SOAP）和消息定义（xsd）。微服务采用简单的文本协议JSON和XML，基于HTTP的资源API风格。如果需要二进制，通过用到Thrift, ProtoBuf, Avro。

服务约定 – 定义接口 – Swagger, RAML, Thrift IDL

如果把功能实现为服务，并发布，需要定义一套约定。单体架构中，SOA采用WSDL，WSDL过于复杂并且和SOAP紧耦合，不适合微服务。

REST设计的微服务，通常采用Swagger和RAML定义约定。

对于不是基于REST设计的微服务，比如Thrift，通常采用IDL（Interface Definition Languages），比如Thrift IDL。

微服务集成 (服务间通信)

大部分微服务基于RPC、HTTP、JSON这样的标准协议，集成不同标准和格式变的不再重要。另外一个选择是采用轻量级的消息总线或者网关，有路由功能，没有复杂的业务逻辑。下面就介绍几种常见的架构方式。

点对点方式

点对点方式中，服务之间直接用。每个微服务都开放REST API，并且调用其它微服务的接口。

上图：通过点对点方式通信

很明显，在比较简单的微服务应用场景下，这种方式还可行，随着应用复杂度的提升，会变得越来越不可维护。这点有些类似SOA的ESB，尽量不采用点对点的集成方式。

API-网关方式

API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能个。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

上图：通过API-网关暴露微服务

所有的业务接口通过API网关暴露，是所有客户端接口的唯一入口。微服务之间的通信也通过API网关。\

采用网关方式有如下优势：

目前，API网关方式应该是微服务架构中应用最广泛的设计模式。

消息代理方式

微服务也可以集成在异步的场景下，通过队列和订阅主题，实现消息的发布和订阅。一个微服务可以是消息的发布者，把消息通过异步的方式发送到队列或者订阅主题下。作为消费者的微服务可以从队列或者主题共获取消息。通过消息中间件把服务之间的直接调用解耦。

上图：异步通信方式

通常异步的生产者/消费者模式，通过AMQP, STOMP, MQTT 等异步消息通讯协议规范。

数据的去中心化

单体架构中，不同功能的服务模块都把数据存储在某个中心数据库中。

每个微服务有自己私有的数据库，其它微服务不能直接访问。单体架构，用一个数据库存储所有数据

微服务方式，多个服务之间的设计相互独立，数据也应该相互独立（比如，某个微服务的数据库结构定义方式改变，可能会中断其它服务）。因此，每个微服务都应该有自己的数据库。

每个微服务有自己私有的数据库，其它微服务不能直接访问。每个微服务有自己私有的数据库，其它微服务不能直接访问。

数据去中心话的核心要点：

数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。

微服务架构的优点：

微服务架构的缺点：

微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。

关于微服务架构的取舍