⑴ 如何用Nginx快速搭建一个安全的微服务架构
教你如何用Nginx搭建一个安全的、快速的微服务架构
今天我们要谈论微服务以及如何使用Nginx构建一个快速的、安全的网络系统。最后，我们将向您展示一个使用Fabric模式如何非常快速和轻松地构建一个微服务的demo。
在我们探讨Fabric模式之前，我想谈一谈微服务并且从Nginx的角度来看这意味着什么。
0：56 - 大转变
微服务已经引起了应用程序架构的重大转变。
当我第一次开始构建应用程序时，他们都是差不多的。幻灯片中所展示的单体架构也象征了应用程序的构造方式。
目前存在着某种类型的虚拟机（VM），对我来说，就是通常的Java。在虚拟机中应用的功能组件以对象的形式存在，这些对象是在内存中相互通讯的，它们将来来回回处理并进行方法调用。偶尔，你会采用诸如通知等机制来接触到其他系统以便获取数据或传递信息。
有了微服务之后，应用程序如何构建的范式是完全不同的了。你的功能组件会从在同一个主机的内存中通过虚拟机相互通讯转变到部署在容器中，并且使用Restful API调用通过HTTP来相互连接。
这是非常强大的，因为它赋予了你功能隔离。它为您提供了更细粒度的可伸缩性，并且你可以获得更好地处理故障的弹性。很多情况下这是简单的事实，你只需要使用HTTP进行跨网络调用。
现在，这种方法也有一些缺点。
一件轶事
我有一个暗黑的秘密，我是一个微软的员工并且从事.Net开发已经很多年了。当我在那儿的时候，我搭建了一个他们的名为Showcase的视频发布平台。
Showcase是一个用来将微软内部发布的所有视频发布到网上的工具。人们可以观看这些视频并进行学习，比如Microsoft Word的使用提示和技巧。这是一个非常受欢迎的平台，我们有很多人使用它，并且其中很多人都会在我们发布的视频上发表评论。
Showcase从一开始就是一个.Net单体应用，随着它日益受欢迎，我们决定应该将它更换为SOA架构。转换是相对容易的。Visual Studio提供了本质上的翻转开关的能力，也就是将你的DLL调用转变为Restful API调用。随着一些小的重构，我们能够让我们的代码运行得相当好。我们也为这些评论和应用内的社区功能使用智能社区服务。
紧密的回路问题
看起来我们是SOA可行的，在我们的首次测试中，一切都工作正常，直到我们将系统切换到我们的Staging环境并开始使用生产环境数据时，我们就会看到一些严重的问题。这些问题在在页面上有很多评论。
这是一个非常受欢迎的平台，其中的一些页面已经有多达2000条评论了。当我们深入这些问题时，我们意识到这些页面需要花费一分钟进行渲染的原因是因为智能社区服务首先需要填充用户名，然后对每一个用户名都需要发起一个对于用户数据库的网络调用来获得用户详细信息并且填充在渲染页面上。这是非常低效的，需要一到两分钟来渲染页面，而在内存中进行通常只需要5到6秒钟。
缓解
当我们经历了发现和解决问题的过程后，我们最终通过一些措施来调整优化系统，比如对所有的请求进行分组。我们缓存了一些数据，最终我们优化了网络来真正的提高性能。
所以，这与微服务有什么关系呢？对的，借助于微服务，你基本上是采用SOA架构的，并且会将其放入超光速引擎中。在SOA架构中所有的对象都是包含在单个虚拟机中并且在其内部管理，在内存中相互通讯，而现在微服务中是使用HTTP进行数据交换的。
当这样做没有问题时，你会获得很好的性能和线性可伸缩性。
Nginx能够很好地与微服务工作
Nginx是一个你可以用来过渡到微服务的最佳工具之一。
关于Nginx和微服务的一些历史。我们从一开始就参与了微服务运动，还是第一个从Docker Hub下载应用的，我们的客户以及那些拥有一些世界上最大的微服务安装量的最终用户广泛地在他们的基础设施使用Nginx。
原因是Nginx很小、很快并且很可靠。
Nginx微服务参考架构
我们还致力于在Nginx内部使用微服务工作已经有一段时间了。这是一个我们已经搭建的程式化的Nginx微服务参考架构，目前正在AWS上运行。
我们拥有6个核心的微服务，它们都运行在Docker容器里。我们决定建立一个多语种的应用，所以每个容器都可以运行不同的语言，我们目前使用了Ruby、Python、PHP、Java和Node.js。
我们搭建了这个使用十二要素应用的系统，稍加修改，就会使其更好地为微服务工作从而可以替代Roku平台。稍后，我们将向您展示一个实际上运行在demo里的应用。
MRA的价值
为什么我们要建立这样一个参考的微服务架构呢？
我们建立这个参考架构是因为我们需要给我们的客户提供构建微服务的蓝图，我们也想在微服务上下文中测试Nginx和Nginx Plus的功能，弄清楚如何才能更好地利用它的优势。最后，我们要确保我们对于微服务生态系统以及其可以给我们提供什么有一个深入的理解。
网络问题
让我们回到我们讨论的大转变。
从将运行在内存里并且被虚拟机管理的你的应用的所有功能组件迁移到通过网络进行工作并且相互通讯的方式，你会本质上引入一系列为了应用有效工作需要你解决的问题。
第一你需要服务发现，第二，你需要在架构中为所有不同的实例进行负载均衡，然后还有第三个，你需要操心性能和安全。
无论是好是坏，这些问题密不可分，你必须做权衡，有希望的是我们有一个可以解决所有这些问题的解决方案。
让我们更深入地看待每一个问题。
服务发现
让我们来谈谈服务发现。在单体应用中，APP引擎会管理所有的对象关系，你永远不必担心一个对象与另一个对象的相对位置，你只需要简单的调用一个方法，虚拟机会连接到对象实例，然后在调用完毕后销毁。
然后有了微服务，你需要考虑那些服务的位置。不幸的是，这不是一个普遍的标准流程。您正在使用的各种服务注册中心，无论是Zookeeper、Consul、etcd或者其它的，都会以不同的方式进行工作。在这个过程中，你需要注册你的服务，还需要能够读取这些服务在哪里并且可以被连接。
负载均衡
第二个问题是关于负载均衡的。当您拥有多个服务实例时，您希望能够轻松地连接到它们，将您的请求在它们中高效地分发，并以最快的方式执行，所以不同实例之间的负载均衡是非常重要的问题。
不幸的是，最简单形式的负载均衡是非常低效的。当你开始使用不同的更加复杂的方案做负载均衡时，它也变得更加复杂并且不易于管理。理想情况下，您希望您的开发人员能够基于他们的应用程序的需求决定何种负载均衡方案。例如，如果你连接到一个有状态的应用程序，你需要拥有持久化，这样可以确保你的Session信息会被保留。
安全和快速通讯
也许微服务最令人生畏的领域是性能和安全。
当在内存中运行时，一切都很快。现在，运行在网络上就会慢了一个数量级。
被安全地包含在一个系统中的信息，通常是二进制格式的，现在会被用文本格式在网络上传输。现在是比较容易在网络上布置嗅探器并能够监听你的应用正在被移动的所有数据。
如果要在传输层加密数据，那么会在连接速率和CPU使用率方面引入显着的开销。SSL/TLS在其全面实施阶段需要九个步骤来初始化一个请求。当你的系统每天需要处理成千上万、几万、数十万或数百万的请求时，这就成为性能的一个重要障碍了。
一个解决方案
我们已经在Nginx开发的一些解决方案，我们认为，会解决所有的这些问题，它赋予你健壮的服务发现、非常棒的用户可配置负载均衡以及安全和快速加密。
网络架构
让我们来谈谈你可以安装和配置你的网络架构的各种方法。
我们提出了三种网络模型，它们本身并不相互排斥，但我们认为它们属于多种格式的。这三种模式是Proxy模式、Router Mesh模式和Fabric模式——这是最复杂的，并在许多方面在其头部进行负载均衡。
Proxy模式
Proxy模式完全聚焦于你的微服务应用的入站流量，并且事实上忽略内部通讯。
你会获得Nginx提供的所有的HTTP流量管理方面的福利。你可以有SSL/TLS终止、流量整形和安全，并且借助于最新版本的Nginx Plus和ModSecurity，你可以获得WAF能力。
你也可以缓存，你可以将Nginx提供给你的单体应用的所有东西添加到你的微服务系统里，并且借助于Nginx Plus，你可以实现服务发现。当你的API实例上下浮动时，Nginx Plus可以在负载均衡工具里动态地添加和减去它们。
Router Mesh模式
Router Mesh模式类似于Proxy模式，在其中我们有一个前端代理服务来管理接入流量，但它也在服务之间添加了集中式的负载均衡。
每个服务连接到集中式的Router Mesh，它管理不同服务之间的连接分发。Router Mesh模式还允许你在熔断器模式中搭建，以便可以对你的应用添加弹性并允许你采取措施来监控和拉回你的失效的服务实例。
不幸的是，因为该模式增加了一个额外的环节，如果你不得不进行SSL/TLS加密，它事实上加剧了性能问题。这就是引入Fabric模式的原因。
Fabric模式
Fabric模式是将其头部的所有东西翻转的模式。
就像之前的另外两个模式一样，在前面会有一个代理服务器来管理流入流量，但与Router Mesh模式不同的地方就是你用运行在每个容器里的Nginx Plus来替代了集中式的Router。
这个Nginx Plus实例对于所有的HTTP流量作为反向和正向代理，使用这个系统，你可以获得服务发现、健壮的负载均衡和最重要的高性能加密网络。
我们将探讨这是如何发生的，以及我们如何处理这项工作。让我们先来看看一个服务如何连接和分发他们的请求结构的正常流程。
正常的流程
在这个图中，你可以看到投资管理器需要跟用户管理器通讯来获取信息。投资管理器创建了一个HTTP客户端，该客户端针对服务注册中心发起了一个DNS请求并获得返回的一个IP地址，接着初始化了一个到用户管理器的SSL/TLS连接，该连接需要通过九阶段的协商或者是”握手”过程。一旦数据传输完毕，虚拟机会关闭连接并进行HTTP客户端的垃圾回收。
整个过程就是这样。这是相当简单和易于理解的。当你把它分解成这些步骤时，您可以看到该模式是如何真正完成请求和响应过程的。
在Fabric模式中，我们已经改变了这一点。
Fabric模式的细节
你会注意到的第一件事是Nginx Plus是运行在每一个服务里的，并且应用程序代码是在本地与Nginx Plus通信的。因为这些是本地连接，你不需要担心加密问题。它们可以是从Java或者PHP代码到Nginx Plus实例的HTTP请求，并且都是在容器内的本地HTTP请求。
你也注意到Nginx Plus会管理到服务注册中心的连接，我们有一个解析器，通过异步查询注册中心的DNS实例来获取所有的用户管理器实例，并且预先建立连接，这样当Java服务需要从用户管理器请求一些数据的时候，可以使用预先建立的连接。
持久的SSL/TLS连接
微服务之间的有状态的、持久化的并且可以加密的连接是真正的益处。
记得在第一个图中服务实例是如何通过一些流程的吧，比如创建HTTP客户端、协商SSL/TLS连接、发起请求并关闭的吗？在这里，Nginx预先建立了微服务之间的连接，并使用Keepalive特性，保持调用之间的持续连接，这样你就不必为每一个请求处理SSL/TLS协商了。
本质上，我们创建了一个迷你的从服务到服务的VPN连接。在我们最初的测试中，我们发现连接速度增加了77%。
熔断器Plus
在Fabric模式以及Router Mesh模式中，你也可以从创建和使用熔断器模式中获得好处。
本质上，您定义了一个在服务内部的活跃的健康检查，并设置缓存，以便在服务不可用的情况下保留数据，从而获得完整的熔断器功能。
所以，现在我可以确定你认为Fabirc模式听起来很酷，并且想在实际环境中跃跃欲试。
⑵ 如何搭建局域网服务器
⑶ 你好，请问服务器地址是填什么
您好，很高兴为您解答。
服务器地址可以指ipv4地址，也可以为ipv6地址。
服务器是指保存有该网络中所有主机的域名和对应IP地址，并具有将域名转换为IP地址功能的服务器。其中域名必须对应一个IP地址，一个域名可以有多个IP地址，而IP地址不一定有域名。
简单的解释就是：服务器地址就是一个IP区，就像一个人有名字一样，你的服务器在网络供应商的网络中也要有一个名字，就是这一IP区就是你服务器的名字。
每个电脑都有个ip地址，服务器也有。但登录服务器大多都是用网址，通过服务器解析，最后指向的还是是那个ip地址加一个访问端口。
客户端IP地址指的是用户机所使用的IP地址。
服务器IP地址是指提供各项服务的服务器的Ip地址，即网络服务器的IP地址。
客户端IP地址和服务器IP地址的分配没有具体要求，但是在同一个网内IP地址不能重复，否则系统会提示IP地址冲突。
(3)创建微服务器地址扩展阅读：
IPv4，是互联网协议（Internet Protocol，IP）的第四版，也是第一个被广泛使用，构成现今互联网技术的基础的协议。地址长度：32位,4字节。
IPv4通常用点分十进制记法书写，例如192.168.0.1，其中的数字都是十进制的数字，中间用实心圆点分隔。
IPv6的优势就在于它大大地扩展了地址的可用空间，IPv6地址有128位长。如果地球表面（含陆地和水面）都覆盖着计算机，那么IPv6允许每平方米拥有7*10^23个IP地址；如果地址分配的速率是每微秒100万个，那么需要10^19年才能将所有的地址分配完毕。
IPv6的128位地址通常写成8组，每组为四个十六进制数的形式。比如：AD80:0000:0000:0000:ABAA:0000:00C2:0002 是一个合法的IPv6地址。
⑷ 微服务入门这一篇就够了
刚开始进入软件行业时还是单体应用的时代，前后端分离的概念都还没普及，开发的时候需要花大量的时间在“强大”的JSP上面，那时候SOA已经算是新技术了。现在，微服务已经大行其道，有哪个互联网产品不说自己是微服务架构呢？
但是，对于微服务的理解每个人都不太一样，这篇文章主要是聊一聊我对微服务的理解以及如何搭建经典的微服务架构，目的是梳理一下自己的一些想法，如果存在不同看法的欢迎指正！
首先，什么是微服务呢？
相对的，要理解什么是微服务，那么可以先理解什么是单体应用，在没有提出微服务的概念的“远古”年代，一个软件应用，往往会将应用所有功能都开发和打包在一起，那时候的一个B/S应用架构往往是这样的：
但是，当用户访问量变大导致一台服务器无法支撑时怎么办呢？加服务器加负载均衡，架构就变成这样了：
后面发现把静态文件独立出来，通过CDN等手段进行加速，可以提升应用的整体相应，单体应用的架构就变成：
上面3中架构都还是单体应用，只是在部署方面进行了优化，所以避免不了单体应用的根本的缺点：
我认为任何技术的演进都是有迹可循的，任何新技术的出现都是为了解决原有技术无法解决的需求，所以，微服务的出现就是因为原来单体应用架构已经无法满足当前互联网产品的技术需求。
在微服务架构之前还有一个概念：SOA（Service-Oriented Architecture）-面向服务的体系架构。我认为的SOA只是一个架构模型的方法论，并不是一个明确而严谨的架构标准，只是后面很多人将SOA与The Open Group的SOA参考模型等同了，认为严格按照TOG-SOA标准的才算真正的SOA架构。SOA就已经提出的面向服务的架构思想，所以微服务应该算是SOA的一种演进吧。
撇开架构先不说，什么样的服务才算微服务呢？
微服务架构，核心是为了解决应用微服务化之后的服务治理问题。
应用微服务化之后，首先遇到的第一个问题就是服务发现问题，一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件： 服务注册中心 ，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单：
解决服务发现问题后，接着需要解决微服务分布式部署带来的第二个问题：服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件： 配置中心 ，微服务架构就变成下面这样了：
以上应用内部的服务治理，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：
上面是一个典型的微服务架构，当然微服务的服务治理还涉及很多内容，比如：
目前国内企业使用的微服务框架主要是Spring Cloud和Dubbo（或者DubboX），但是Dubbo那两年的停更严重打击了开发人员对它的信心，Spring Cloud已经逐渐成为主流，比较两个框架的优劣势的文章在网上有很多，这里就不重复了，选择什么框架还是按业务需求来吧，业务框架决定技术框架。
Spring Cloud全家桶提供了各种各样的组件，基本可以覆盖微服务的服务治理的方方面面，以下列出了Spring Cloud一些常用组件：
本章节主要介绍如何基于Spring Cloud相关组件搭建一个典型的微服务架构。
首先，创建一个Maven父项目 spring-cloud-examples ，用于管理项目依赖包版本。由于Spring Cloud组件很多，为保证不同组件之间的兼容性，一般通过 spring-cloud-dependencies 统一管理Spring Cloud组件版本，而非每个组件单独引入。
pom.xml配置如下：
参考上面业务服务A搭建另外一个业务服务B。
目前网上很多说是下一代微服务架构就是Service Mesh，Service Mesh主流框架有Linkerd和Istio，其中Istio有大厂加持所以呼声更高。Service Mesh我接触还不多，但是个人感觉并不一定能称为下一代微服务架构，可能认为是服务治理的另外一种解决方案更合适，是否能够取代当前的微服务架构还需要持续观察。
⑸ 使用小米路由器3作为服务器怎么设置
如今的网络时代,很多人都想拥有自己的服务器,不想花钱购买各种虚拟空间产品,而小米路由器3正好可以当做微型服务器使用.使用小米路由器3作为服务器的设置 方法 其实很简单，下面由我告诉你!
使用小米路由器3作为服务器的设置方法
首先,要把小米路由器3当服务器玩的话,需要先开启SSH功能!链接地址:位于"工具/原料"请按照官方提示开启SSH功能，注意:开启SSH功能将会失去保修!!
当按照官方提示步骤开启SSH成功的时候,就需要使用到putty了(可以自行网络下载)
当下载好软件解压后,打开putty.exe按照图片步骤去操作,IP地址为路由器IP地址,默认为192.168.31.1在这里我把路由器的IP修过成了192.168.31.2,所以我输入的就是192.168.31.2
输入完成,点击"OPEN"之后会弹出类似命令行的窗口,然后就输入账号"root"并点击回车 然后输入密码,密码是你在ssh页面里面的那个ROOT密码!输入的时候不会显示,输入完后点击回车,如果显示" Welcome to XiaoQiang!",那么就登录成功了,不行的话就是密码错了,请重新尝试!然后我们就可以下一步了!
输入以下命令并点击回车
vi /etc/sysapitpd/sysapihpd.conf
然后按着方向键下到尾部 编辑文本添加第五步的内容(可以在文本空白处随便输入英文字符,然后当左下角显示"I"的时候便可以编辑,但需要删除乱输入的字符!若无意修改了其他文本,可以通过按Ctrl+Z键撤销修过,然后重复上面的步骤)
server {
listen 8080;
server_name _;
access_log off;
location / {
root /extdisks/sda1/WEB;
index index.html index.htm;
}
error_page 404 404.html;
error_page 500 502 503 504 50x.html;
location = 50x.html {
root html;
}
}
这里提示一下:1. listen 后面的数字是端 口号 ,在访问的时候需要用到!2. "root /extdisks/sda1/WEB"是指路由器后面USB接口接的U盘或者硬盘的路径,WEB是U盘或者硬盘里面的文件夹,这里的意思就是我把网页文件都放在了U盘:/WEB 文件夹中3. index 是首选主页文件4. error_page 是当服务器发生错误的时候的自定义错误页面，编辑后如图所示
编辑完成第五步的内容后,按ESC键,左下角显示"-",然后输入大写Z两次(可以点击大写锁定"Caps Lock"后双击Z键,又可以按住"Shift"然后双击Z键)然后输入以下命令并点击回车重启配置
/etc/init.d/sysapihpd restart
注意不可以出现"error"字样,不然就是出现错误了,灰常需要注意文本里面的花括号位置,看清楚再修改!!如图为正常情况
当上面的步骤都完成后,相信内网已经可以访问了 打开浏览器,输入192.168.31.1:8080 (我的是192.168.31.200.1406)只是IP和端口号不同,这些都可以自定义的!需要现在连接路由器的U盘或硬盘中的WEB文件夹放入首页文件,例如index.html,否则可能会显示拒绝访问PS:我一开始在尝试的时候,改过很多次IP..
接下来需要设置的,便是外网访问了...首先,要让外网访问就必须修过防火墙配置 在putty输入
vi /etc/config/firewall
按着方向键下到最后一行,添加代码
config rule 'htdwan'
option src 'wan'
option dest_port '8080'
option proto 'tcp'
option target 'ACCEPT'
option name ''\''hpd wan accept tcp port 8080'\'''
(我是以前弄的,所以,已经不是最后一行了"option dest_port "为端口号,可以自定义)然后用上面同样的方法保存
重启防火墙配置以使其生效
在putty输入
/etc/init.d/firewall restart
如图,然后就可以啦
最后一步,设置域名解析，打开路由器设置页面,按照图片提示设置，高级设置-DDNS
最后,通过外网链接访问,成功!
END