技术栈（technology stack）

技术栈： 产品实现上依赖的软件基础组件， 包括

1、 系统

2、 中间件

3、 数据库

4、 应用软件

5、 开发语言

6、 框架

 

---

一、前端技术
笔者认为后台开发人员掌握一定的前端技术是必要的，作为JAVA开发最起码的JSP、JQuery、BootStrap这些你得有起码的了解。除此之外，前后端的交互技术，AJAX、JSON、JSONP也是必须了解和掌握的。

二、通信协议
通信协议就跟上面说的网络编程这门课程有很大的关系，通信协议通俗一点说就是：客户端和服务器通信的格式，大家都知道报文是二进制的，而协议的作用就是规定了某一位或某几位二进制串的作用，规定了报文应该按照怎么样的格式来编码。如果违反了这个协议，那么报文是不可能被客户端或服务器正确解码的。
大家最熟悉的协议大概就是HTTP，HTTP协议具体的报文格式也不需要再过多的介绍了。在这里，大家可以思考一个问题，如果一个公司或者实验室内部调用的接口，是不是也需要HTTP协议来通信呢？笔者认为这是一个最差的方案，因为HTTP的报文头部比较长，内部的接口调用是不需要那么复杂的头部的，所以一般采用的是RPC协议。

RPC全称远程过程调用，通过它可是实现一台服务器去调用另外一台服务器上的方法，是基于TCP/IP协议上的一个协议。举个栗子，B服务器上有b1()和b2()两个方法，首先需要向服务注册与发现设备进行注册，A服务器想要调用b1()时，向服务注册与发现设备查询b1()方法所属服务器的IP和端口，得到后，将A服务器的请求路由到该IP的制定端口上。那么通信协议在这个流程中的作用是什么呢？A服务器想要请求b1()方法，他的请求发送到服务注册与发现设备之后，该设备需要通过规定的通信协议来识别该请求报文具体请求的服务名，由此来查询该服务的IP及端口，这个过程叫做路由。HTTP协议中，是通过URL来进行路由的。在RPC过程中，我们一般使用自己定义的协议来减少报文的长度，最简单的方法是通过一个唯一的整形来进行路由，具体的路由方案有很多，这里不再过多赘述。所以我们来总结一下，通信协议规定了通信的格式，他可以规定某几位为路由数，某几位为请求报文的body，一个很简单的通信协议头部有路由字段就可以满足了，相比于HTTP的头部而已，轻量了很多。body里面存的就是请求的具体参数和响应结果了，该区域一般也是有数据传输协议来进行数据的编码的，json是一种选择，而另一种更好的选择就是谷歌的protocol buffer，相比于json而言，它是二进制的，更轻量，具体的特性和使用方法会在后面的文章中进行介绍。笔者最经常用的一个RPC框架是Thrift，也会在后面的文章中将会给大家介绍。

三、负载均衡
负载均衡这个词，相信大家接触得都很多。负载均衡就是用多台应用服务器来完成一个业务，通过负载均衡中间件对这些服务器的负载情况进行一个管理及动态的调整，以尽量消除或减少各服务器负载不均衡的现象。还是上一节当中的那个栗子，当B服务器的请求量很大时，一台服务器是无法支撑起整个业务的，于是我们对该服务器做一个扩展，变成三台服务器B1、B2、B3共同来提供服务，他们三台服务器的IP和端口首先都需要向服务注册与发现设备来进行注册，同时这三台服务器的负载量由负载均衡服务器进行管理，这是A服务器对于b1()方法的一个请求到达负载均衡服务器，负载均衡服务器需要去请求服务注册于发现设备该方法的路由地址列表，拿到该列表后从中选择负载量最优的那一台服务器，将A服务器的请求路由至那台服务器上。
在公司里面，负载均衡层一般都由运维负责，笔者还接触不到这些，只能大略地介绍一些，如果大家想要深入地学习，可以先学习下使用nginx来搭建负载均衡服务器。
四、反向代理
反向代理是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端。通俗点讲，ABC三个人，A想向C问个问题，但是得通过B来进行。A先告诉B，B再去问C，最后B将C的回答转述给A。可能大家会觉得为什么需要这么麻烦的过程呢，A直接问C不就好了。大家这个时候可以打开一个网页，按一下F12，选择network选项卡，然后F5刷新一下网页，在这个选项卡里，会刷出一个列表，这个列表就是你刷新一次网页浏览器需要向服务器发送的请求列表。我们知道，一个HTTP请求是只能请求一个对象的，一个网页里有10个图片就需要请求10次，实际上你刷新一个网页时，大部分的请求都是静态元素，即图片、js或css等文件，如果这些大部分的请求都需要通过应用服务器来完成的话，会给应用服务器带来很大的负担，所以反向代理的作用，就是缓存这些静态文件，当浏览器发送一个请求时，反向代理服务器判断请求内容是否是它缓存内容，如果是，就可以直接将结果返回；如果不是，反向代理再将该请求转发至应用服务器上处理。这样，就减少了应用服务器的负担。常用的反向代理——nginx。

有人可能会说，nginx好厉害啊，项目部署用一台nginx就可以完成负载均衡和反向代理了。实际上是需要两台nginx来架构的，一台放再lvs中负责负载，另一台部署在tomcat前，负责反向代理。

五、业务编程

通过上面四点的介绍，一个请求已经能从客户端发送至应用服务器tomcat上了。接下来就是根据服务器编程完成相应的业务流程。后台常用的开发框架笔者都有接触并且用过不短时间，Stuts2、Spring MVC、Spring、Hibernate、MyBatis这些。一般两套常用的体系是Struts2+Spring+Hibernate和Spring MVC+Spring+MyBatis，很明显Spring的作用不言而喻。这两套体系都是MVC设计思想的体现。对比下这两套体系，Struts2和Spring MVC都是Controller层的框架，后者对初学者更友好一些，而且前者经常出现一些神奇的BUG，公司里面也是很不喜欢使用的，所以强烈推荐的是Spring MVC。Hibernate和MyBatis都是两个比较重用的持久层框架，Hibernate会比Mybatis好入门一些，但是MyBatis会比Hibernate轻量，使用广泛程度也差不多。

六、数据库

数据库需要掌握的：sql语句、索引、explain性能分析等

七、缓存

缓存分本地缓存和缓存服务器。本地缓存指的是将数据缓存下本地的内存中，一般对一些读业务的数据采用本地缓存，推荐大家学习下google的guava cache。缓存服务器的话推荐redis，一个键值对的缓存，比较适合入门

除了上面的这些，还有maven svn git这些工具也是需要掌握的
 

---

分布式技术栈

构建分布式系统的目的是增加系统容量，提高系统的可用性，转换成技术方面，也就是完成下面两件事。

• 大流量处理。通过集群技术把大规模并发请求的负载分散到不同的机器上。
• 关键业务保护。提高后台服务的可用性，把故障隔离起来阻止多米诺骨牌效应（雪崩效应）。如果流量过大，需要对业务降级，以保护关键业务流转。

说白了就是干两件事。一是提高整体架构的吞吐量，服务更多的并发和流量，二是为了提高系统的稳定性，让系统的可用性更高。

提高架构的性能

 

 

咱们先来看看，提高系统性能的常用技术。

• 缓存系统。加入缓存系统，可以有效地提高系统的访问能力。从前端的浏览器，到网络，再到后端的服务，底层的数据库、文件系统、硬盘和 CPU，全都有缓存，这是提高快速访问能力最有效的手段。对于分布式系统下的缓存系统，需要的是一个缓存集群。这其中需要一个 Proxy 来做缓存的分片和路由。

• 负载均衡系统，是做水平扩展的关键技术。其可以用多台机器来共同分担一部分流量请求。

• 异步调用。异步系统主要通过消息队列来对请求做排队处理，这样可以把前端的请求的峰值给“削平”了，而后端通过自己能够处理的速度来处理请求。这样可以增加系统的吞吐量，但是实时性就差很多了。同时，还会引入消息丢失的问题，所以要对消息做持久化，这会造成“有状态”的结点，从而增加了服务调度的难度。

• 数据分区和数据镜像。数据分区是把数据按一定的方式分成多个区（比如通过地理位置），不同的数据区来分担不同区的流量。这需要一个数据路由的中间件，会导致跨库的 Join 和跨库的事务非常复杂。而数据镜像是把一个数据库镜像成多份一样的数据，这样就不需要数据路由的中间件了。你可以在任意结点上进行读写，内部会自行同步数据。然而，数据镜像中最大的问题就是数据的一致性问题。

对于一般公司来说，在初期，会使用读写分离的数据镜像方式，而后期会采用分库分表的方式。

提高架构的稳定性

 

 

接下来，咱们来看看提高系统系统稳定性的一些常用技术。

• 服务拆分，主要有两个目的：一是为了隔离故障，二是为了重用服务模块。但服务拆分完之后，会引入服务调用间的依赖问题。

• 服务冗余，是为了去除单点故障，并可以支持服务的弹性伸缩，以及故障迁移。然而，对于一些有状态的服务来说，冗余这些有状态的服务带来了更高的复杂性。其中一个是弹性伸缩时，需要考虑数据的复制或是重新分片，迁移的时候还要迁移数据到其它机器上。

• 限流降级。当系统实在扛不住压力时，只能通过限流或者功能降级的方式来停掉一部分服务，或是拒绝一部分用户，以确保整个架构不会挂掉。这些技术属于保护措施。

• 高可用架构，通常来说是从冗余架构的角度来保障可用性。比如，多租户隔离，灾备多活，或是数据可以在其中复制保持一致性的集群。总之，就是为了不出单点故障。

• 高可用运维，指的是 DevOps 中的 CI（持续集成）/CD（持续部署）。一个良好的运维应该是一条很流畅的软件发布管线，其中做了足够的自动化测试，还可以做相应的灰度发布，以及对线上系统的自动化控制。这样，可以做到“计划内”或是“非计划内”的宕机事件的时长最短。

上述这些技术非常有技术含量，而且需要投入大量的时间和精力。

分布式系统的关键技术

而通过上面的分析，我们可以看到，引入分布式系统，会引入一堆技术问题，需要从以下几个方面来解决。

• 服务治理。服务拆分、服务调用、服务发现，服务依赖，服务的关键度定义……服务治理的最大意义是需要把服务间的依赖关系、服务调用链，以及关键的服务给梳理出来，并对这些服务进行性能和可用性方面的管理。

• 架构软件管理。服务之间有依赖，而且有兼容性问题，所以，整体服务所形成的架构需要有架构版本管理、整体架构的生命周期管理，以及对服务的编排、聚合、事务处理等服务调度功能。

• DevOps。分布式系统可以更为快速地更新服务，但是对于服务的测试和部署都会是挑战。所以，还需要 DevOps 的全流程，其中包括环境构建、持续集成、持续部署等。

• 自动化运维。有了 DevOps 后，我们就可以对服务进行自动伸缩、故障迁移、配置管理、状态管理等一系列的自动化运维技术了。

• 资源调度管理。应用层的自动化运维需要基础层的调度支持，也就是云计算 IaaS 层的计算、存储、网络等资源调度、隔离和管理。

• 整体架构监控。如果没有一个好的监控系统，那么自动化运维和资源调度管理只可能成为一个泡影，因为监控系统是你的眼睛。没有眼睛，没有数据，就无法进行高效的运维。所以说，监控是非常重要的部分。这里的监控需要对三层系统（应用层、中间件层、基础层）进行监控。

• 流量控制。最后是我们的流量控制，负载均衡、服务路由、熔断、降级、限流等和流量相关的调度都会在这里，包括灰度发布之类的功能也在这里。

此时，你会发现，要做好这么多的技术，或是要具备这么多的能力，简直就是一个门槛，是一个成本巨高无比的技术栈，看着就都头晕。要实现出来得投入多少人力、物力和时间啊。是的，这就是分布式系统中最大的坑。

不过，我们应该庆幸自己生活在了一个非常不错的年代。今天有一个技术叫——Docker，通过 Docker 以及其衍生出来的 Kubernetes 之类的软件或解决方案，大大地降低了做上面很多事情的门槛。Docker 把软件和其运行的环境打成一个包，然后比较轻量级地启动和运行。在运行过程中，因为软件变成了服务可能会改变现有的环境。但是没关系，当你重新启动一个 Docker 的时候，环境又会变成初始化状态。

这样一来，我们就可以利用 Docker 的这个特性来把软件在不同的机器上进行部署、调度和管理。如果没有 Docker 或是 Kubernetes，那么你可以认为我们还活在“原始时代”。现在你知道为什么 Docker 这样的容器化虚拟化技术是未来了吧。因为分布式系统已经是完全不可逆转的技术趋势了。

但是，上面还有很多的技术是 Docker 及其周边技术没有解决的，所以，依然还有很多事情要做。那么，如果是一个一个地去做这些技术的话，就像是我们在撑开一张网里面一个一个的网眼，本质上这是使蛮力的做法。我们希望可以找到系统的“纲”，一把就能张开整张网。那么，这个纲在哪里呢？

分布式系统的“纲”

总结一下上面讲述的内容，你不难发现，分布式系统有五个关键技术，它们是：

• 全栈系统监控；
• 服务 / 资源调度；
• 流量调度；
• 状态 / 数据调度；
• 开发和运维的自动化。

而最后一项——开发和运维的自动化，是需要把前四项都做到了，才有可能实现的。所以，最为关键是下面这四项技术，即应用整体监控、资源和服务调度、状态和数据调度及流量调度，它们是构建分布式系统最最核心的东西。

 

链接：https://www.jianshu.com/p/1e86f615a187