微服务1

今天是9.21日，像我之前说过的，对于所有知识点的整理我现在都不会讲的特别清晰（因为我写了那么多，一个点赞都没有，呜呜呜），开个玩笑，确实是之前的方法效率太低了，所有这次在学习微服务的时候还是想以我自己的学习路径来作记录，毕竟我只是一个普通的大学生，不指望靠文章来赚流量啥的，对于我来说，写博客应该算是一个记录工具，我想对于很多的读者也是一样的。

浅谈tomcat和Nginx

今天简单回顾了一下服务器、ip地址、域名之间的联系：
服务器：为了协助开发网络业务用来存放和处理数据的工具，一般存在机房里。
ip地址：相当于服务器的标识，是每台服务器必备的东西，用来作为用户和服务器之间的连接。
域名：服务器可以有多个域名，可以多个域名（相当于多个网站指引）解析一个ip地址（一台服务器）。

于是乎就有了web服务器和web应用服务器的概念：（可参考负载均衡，动静态分离等概念）

常见的web服务器有：apache,Nginx（http服务器）,IIS（常作为代理服务器）
常见的web应用服务器有：Tomcat,resin,jetty
区别：web服务器不能解析jsp等页面，只能处理js、css、html等静态资源
并发能力：web服务器的并发能力远高于web应用服务器

Nginx和Tomcat结合方式：

将所有静态页面交给nginx，动态请求交给后端tomcat处理。
将所有请求交给后端tomcat服务器处理，只利用Nginx自身的负载均衡功能进行多台tomcat服务器调度流量。

吃透API网关

这是今天内容的重心，参照原文链接：https://www.jianshu.com/p/7baab672b822
先谈传统单体应用的框架，在那时候功能常常被集中在一个应用里（一个应用服务器tomcat），进行集中部署，统一测试，但是这种情况下随着需求的变更，在更新功能模块时就需要对所有的程序进行更新，那么整体就会变得非常难以维护，而在微服务时代，集中于一体的功能被拆分了，每个功能模块都有自己的体系及运维，所以既然对功能模块进行了拆分，那么最终要想封装成一个完整的工程，就需要用到API网关，于是乎，微服务的架构就变成了：客户通过ios/android、PC端通过API对接API网关，而API网关则根据客户的需求对单独的服务进行协议转换，从而将工作转移到单一的模块上：
图片说明
那么API网关和单体应用时期的代理（Nginx）有什么区别呢：代理是纯粹的数据透传，协议不会发生变化；网关在数据透传的背景下，还会设计协议的转换，比如上图中用户请求传输到网关的协议是HTTP，通过网关透传到下游则可能已经转换成企业内部的RPC了(比如JSF、Dubbo等企业自研的RPC框架)。
所以用一句话来概括API网关的功能，那就是一个API网关包含了统一接入、协议适配、流量管理与容错、以及安全防护这四大功能。

这里再引用文章里的一个架构示例来对API网关进行一个说明：网关运行良好的环境还包括注册中心（比如：ZK读取已发布的API接口的动态配置）。为了实现高性能，将数据全部异构到缓存（如：Redis）中，同时还可以配合本地缓存来进一步提高网关系统的性能。为了提高网关的吞吐率，可以使用NIO+Servlet 3 异步的方式，还可以利用Servlet 3 的异步特性将请求线程与业务线程分开，为后续的线程池隔离做好基本的支撑。访问日志的存储我们可以放到Hbase中，如果要作为开放网关使用，那么需要一个支持OAuth2.0的授权中心。还可以引入Nginx + lua的方式将一些基本的校验判断放到应用系统之上，这样可以更轻量化的处理接入的问题，整体的网关架构示例如下所示：
图片说明

总结：API网关的介绍到这就差不多了，服务器ip域名啥的都是在看这篇文章中重新回顾的，接下来就要接触第一个分布式服务框架：Dubbo.

首先我是第一天接触Dubbo，所以不可能今天就把Dubbo给实践用上，所以今天主要是摸清Dubbo的核心概念，为后续的应用建立基础，不然就是照猫画虎，就算你把Dubbo给搭建起来了，但是问啥啥不知，就只学会c+v了。
对于现在的我来说，我目前只用过spring boot，这是一个基于spring的一个开发框架，那么今天就先对比一下springboot和Dubbo，首先我们知道springboot它的传输协议是参照Restful规则的，而阿里的Dubbo则是通过RPC（远程调用）的分布式服务框架，那么就要谈谈RPC和Restful的区别：
1、从本质区别上看，RPC是基于TCP实现的，RESTFUL是基于HTTP来实现的。
2、从传输速度上来看，因为HTTP封装的数据量更多所以数据传输量更大，所以RPC的传输速度是比RESTFUL更快的。（效率更高）
3、因为HTTP协议是各个框架都普遍支持的。在一般情况下，因为不知道情况来源的框架、数据形势是什么样的，所以在网关可以使用Restful利用http来接受。而在微服务内部的各模块之间因为各协议方案是公司内部自己定的，所以知道各种数据方式，可以使用TCP传输以使各模块之间的数据传输更快。所以可以网关和外界的数据传输使用RESTFUL，微服务内部的各模块之间使用RPC。
4、RESTFUL的API的设计上是面向资源的，对于同一资源的获取、传输、修改可以使用GET、POST、PUT来对同一个URL进行区别，而RPC通常把动词直接体现在URL上

总结：RPC服务和HTTP服务还是存在很多的不同点的，一般来说，RPC服务主要是针对大型企业的，而HTTP服务主要是针对小企业的，因为RPC效率更高，而HTTP服务开发迭代会更快。总之，选用什么样的框架不是按照市场上流行什么而决定的，而是要对整个项目进行完整地评估，从而在仔细比较两种开发框架对于整个项目的影响，最后再决定什么才是最适合这个项目的。一定不要为了使用RPC而每个项目都用RPC，而是要因地制宜，具体情况具体分析。

有关Dubbo的简介太多了，这里就不一一写出来了，具体可以参考这个博客：https://www.jianshu.com/p/3090d63e9cb3以及apache官方的Dubbo文档：https://dubbo.apache.org/zh-cn/docs/user/quick-start.html这两个掌握后对Dubbo就有了一个大致的了解了。