前言
这篇创作的初衷其实也是看了很多大神们的总结后，油然而生的一个想法，唉，我是不是也可以总结一下，顺便帮助自己把思路再熟悉一下，当然如果对你有一丁点的帮助将是我莫大的荣幸，所以这篇就来了。本来以为可能需要花费一周的时间来准备材料，后来由于工作的原因，就想到哪里写到哪里了，话不多说，上图。
正文
如上所说本来是想拿网上一个的简单的系统来抛砖引玉，但是还是算了吧（以后有时间再补充吧），上来就干，就是我的风格。有的人看了这个图之后就纳闷了，我一个搞java的，你给前端知识干什么，小伙子，你是不是没有听说过全栈呀，另外以前前后端不分离的时候，都是后端写的前端呀，当然现在难度大了，毕竟前端现在发展那叫一个光速呀，前面框架刚学会，又出来一个新框架，还更好，你说找谁说理去，真是欲哭无泪呀，扯远了，扯远了，来，一、二、三，收！
前端
这两年没有写过前端了，以前写的还是用JQuery和Easy-UI，也用过一点vue，现在听说比较流行的是vue、react，并且为了适应不断的前端需求变化，都是前后端分离的，所以肯定需要自己的打包工具，webpack就用上了，至于开发工具，因人而异吧，Sublime Text、WebStorm都行，仓库管理工具Git。
好，前端说完了，那是不是要说说后端了，别急，小兄弟，数据都是存储在后端的，那么前端是怎么样去后端拿数据的，之间又是怎么交互的，通常我们所说的都是后端提供接口给前端来调用，这个时候网络协议开始粉墨登场，HTTP请求，再熟悉不过了，什么get请求、post请求、put请求等，这个没有问题，那么请求的参数呢，什么格式的，AJAX，Asynchronous Javascript And XML，当然参数支持XML和JSON格式，但是JSON格式后端接受要使用@ResquestBody注解，当然随着技术的不断更新的，后来又出现了AXIOS、FETCH交互方式，号称更好更安全。
上面正好提到了网络协议，正好这里一起讲了，正常的OSI模型分层是7层，应用、表示、会话、传输、网络、数据链路、物理，但是按照TCP/IP分层是4层，应用、传输、网络、链路，其实不管怎么分，总体还是一样只是粒度不一样罢了，正常我们所说的主要协议是HTTP、HTTPS、TCP、IP，其中处于安全考虑，HTTP基本都被HTTPS取代了，TCP常见的三次握手、四次挥手也是重点。
后端
在讲后端技术之前我们有必要先说下DNS和CDN，首先我们需要知道当我们输入网址到页面正常展示到底发生了什么，第一就是域名，需要知道什么是顶级域名、二级域名、三级域名等，如：https://www.baidu.com,其中.com就是顶级域名，baidu就是二级域名，www.指的是万维网，其实就是我们去查域名的地方，https前面说过了。最终我们将域名解析为具体的ip地址，然后请求返回结果，渲染页面，但是随着现在互联网用户的暴增，如果厂商只有一台服务器在北京，全国的用户都要请求北京这台服务器的资源，延迟性可见一一般，这个时候CDN加速器出场了，其实就是缓存的原理，既然都访问北京比较慢，那么就在全国重点城市设立CDN节点，缓存北京服务器中部分数据，用户请求的时候根据用户ip来选择最佳的CDN节点获取内容，如果没有才请求北京的资源并缓存到离用户最近的CDN节点上，其实这个跟物流在全国各个地方建仓库是一个道理。
好，接下来终于到了真正的后端技术了，想想都TM都有点小激动，别废话，开整！
说到后端你敢不说Spring，我打不死你，从以前的spring+SpringMVC+某某，到现在的Spring Boot+某某，这个是生产力的提升了有没有，什么?没有用过Spring+SpringMVC，看来你没有被配置文件恶心到的前车之鉴了，终于Spring的官方也被恶心的不行了，这样Spring Boot横空出世，虽然也只是把原先的Spring和SpringMVC包装了一下，但是终于不用为了繁琐的配置焦头烂额了，就像Spring Boot的口号一样“约定优于配置”。另外Spring大家族中的其他干哥哥，亲表舅的都需要看看，如Spring Cloud Netflix，涉及Eureka(服务注册与发现)、Hystrix(容错管理，实现断路器模式)、Ribbon(客户端负载均衡)、Feign(声明式服务调用组件)、Zuul(网关，提供智能路由、访问过滤等功能)等，Spring Cloud Config，Spring Cloud Bus，Spring Security都需要了解。
说完了Spring接下来说下负载均衡和反向代理吧，果然是符合我一贯的风格，想到哪里说哪里。但是在这之前需要说下服务架构的演变。
- 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本，也就是单一应用架构，用于简化增删改查工作量的 数据访问框架(ORM)是瓶颈。
- 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率，形成了垂直应用架构 ，用于加速前端页面开发的 Web框架(MVC) 是瓶颈。
- 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求，这就是分布式服务架构，用于提高业务复用及整合的 分布式服务框架(RPC) 是瓶颈。
- 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率，最后形成流动计算架构，用于提高机器利用率的 资源调度和治理中心(SOA) 是瓶颈。
看到了上面的服务架构演变，我们可以看到负载均衡、反向代理在所难免了，Nginx就能够满足这些，当然其他的也是能够满足的，得看你具体的业务需求了，如：Haproxy、LVS等。包括一些流量管理、安全隔离、服务容错等知识。
接下来就是框架的核心了，不急，咋们慢慢来。
上面说服务框架演变的时候正好说到了RPC，其实就是远程调用，通俗的话说就是调用远程的服务就像调用本地的一样，想想都觉得牛逼。所以dubbo/dubbox就能帮你干这事，最初是由阿里开源，后来当当网在之前的基础上做了扩展。另外springCloud也有相关的RPC组件，当然现在大公司都有自己的一套的RPC框架，但是原理都是一样的，服务的注册与发现。
说到服务注册，我们就需要讲讲ZooKeeper了，这个组件最初是Hadoop的一个子项目，在2010年10月升级成Apache Software
Foundation(ASF)顶级项目，可见后来晋升了，地位也上去了，在分布式协作服务方面的是一霸，另外因为他的临时节点可以作为分布式锁的实现方式。其他的组件请自行学习，如Consul，Eureka。
注册说完了，那么服务之间的通信又是怎样的呢，大家知道dubbo设计的初衷是为了解决服务之间调用量大，传输数据小而生的，传统的IO传输肯定不合适，那么NIO就是很好的选择，果然dubbo使用的NIO框架是Netty，其他的NIO框架请自行了解。
说到这里实在有点干舌燥，身体疲软，但是作为一个有韧性的当代好青年，耳边突然响起，扶我起来，我要打十个！！！顿时一股鸡血涌上头脑，慢血复活。
哎，说到哪里了，哦，上面说的都很正确，也没有问题，我是谁？？？我在那儿？？？我在干什么？？？
可是有一个问题，假如在秒杀的时候我不能一个一个的去处理，处理完了，才给用户结果吧，所以就需要异步解耦，也能够缩短我们的调用链，提高访问效率。kafka、rabbitmq、rocketmq这些就映入了眼帘，其中为分布式而生的就是kafka，但是听说rabbitmq更加安全的，反正都需要自行去了解，特别是消息的丢失与重复怎么解决。
讲了这么多，终于需要访问并存储数据了，所以就用到了持久化框架MyBatis、Hibernate，我现在基本上都是使用MyBatis，顺便说下关系型数据库，有Oracle、MySQL/MariaDB、SQL Server、PostgrcSQL、DB2等，当然还有阿里自研的OceanBase。
随着数据量的增大，查询的效率也变的越来越低，而用户也对页面响应的要求越来越高，特别是用户的一些热点数据，面对这个问题我们怎么解决呢？分布式缓存，基于非关系型数据库高效的访问效率和支持高并发量的特点来完成，每次用户的热点数据都会先查询非关系型数据库，查询不到再查询关系型数据库并更新缓存，目前主要使用的有Redis、Memcached，从目前的市场的使用情况来看，Redis的潜力会更大一点，它还支持数据持久化到数据库（RDB、AOF）、分布式锁实现（基于lua表达式的原子性）。但是这个过程中需要考虑数据的一致性以及缓存击穿、缓存穿透、缓存雪崩等问题。
上面说到了缓存解决了用户请求慢的问题，但是随着数据量的增加，单表的数据量不断增加，特别是对于主表来说，所以分库分表在所难免，也就是涉及到了数据迁移，这个过程中需要考虑一个主键重复的问题，分布式Id是解决问题的关键，雪花算法了解一下。另外分库分表中间件Cobar、MyCAT、TDDL、Sharding-JDBC熟悉一下。这些中间件虽然能够帮助我们解决很多得问题，但是同时也带来了更多的人力成本和风险，请自行领会。
都说现在的竞争其实就是流量的竞争，说的一点都不错，看看微信、抖音、支付宝、淘宝、京东、拼多多，那个不是在抢夺流量，流量意味着数据，未来数据才是我们的核心价值，所以市场上也出现了很多的数据贩卖公司，请执法部门严厉打击，绝不姑息。数据都有了，怎么将数据转化成有价值的信息，数据分析来了，难怪这几年数据分析师这么吃香。大数据分析框架也跟着吃香，从最初的hadoop，到后来的Storm、Samza、Spark、Flink。搞的我现在就想搞点数据分析一波，可是不会呀！！！
好，说完上面的知识，基本上整个大的流程都已经说完了，觉得我们可以开始搭环境、码代码、然后交付项目了，可是交付的过程总是困难重重，一不小心弄出一个重大事故，那可就得不偿失了，你说最后这一哆嗦怪谁呢。不要怕，容器技术来了，感觉再也不慌了，心跳一下子恢复到往日的180，所以Kubernetes（k8s）、Docker你准备好了么？？？
项目部署完成，也开始投入使用了，但是每天都是各种各样的客诉问题，搞的人真是烦的要死，又要查日志，我的天，你不会让我去每一台机器上面查找日志吧，所以这个时候有个搜索工具是多么的贴心呀，来吧我的小可爱，Elasticsearch，终于过上现代人的生活，其他的搜索引擎请自行了解哈，如：Solr、Apache Lucene
好了，关于后端部分基本说完了，但是似乎工具这块没说，果然我真的是想到哪里写到哪里呀！！！
开发工具IDEA不用说了吧，开发神器，事半功倍，界面酷炫叼炸天，当然eclipse现在也不差，看个人吧。Git远程仓库管理，别说什么svn了，还是老实用Git吧，maven版本控制工具，就是这样简单。Jenkins持续化集成打包工具，sonarQube代码检查工具，与Jenkins配合天衣无缝。一般大公司都是有自己的持续化集成和代码检查工具的，不用你操心。
后记
终于成功码字码到颈椎病犯了，但是依然强忍着疼痛，写完这最后的倔强。可能你已经注意到我基本上写的都是一些大的框架或者知识，对于一些细枝末节的知识点并不涉及，比如java基础知识，还有分布式事务，linux的基础知识，设计模式、JVM等这些都需要你们自己主动去研究。学习的过程就是由点线，然后由线到面，最终形成知识面。祝大家好运！
