谈一个大型的互联网应用系统使用的技术方案汇总（架构师应具备的基本常识）

开篇总得说点什么

随着现在技术的演进，分布式微服务几乎会出现在我们所见的任何大型互联网应用系统中，单体应用几乎再难以支撑我们现在的互联网流量压力。一个系统从单体应用逐渐发展成为集群架构，再慢慢的演变成分布式微服务架构，技术上需要一系列的独立系统与组件支持其运维发展。我们今天只从技术应用领域谈一下一个大型的互联网应用系统在发展过程中涉及到的技术方案与手段。

数据库

一切的一切都是数据在说话，一个软件架构离不开数据库的支持。

1. 关系型数据库：虽然最近NoSql很火，但是其一直替代不了关系型数据库的位置。其原因就是因为关系型数据库强大的关系支持与早已很稳定的数据库事务。代表作：Mysql、Oracle，并且一个应用系统建立之初肯定最先考虑关系数据库的支持，在现在的工作场景中，开发、运维甚至测试和产品对标准sql 的掌握基本已成为必备工作技能。
2. 非关系型数据库和缓存数据库：缓存数据库算是一类特殊的非关系数据库，例如Redis，memcached以其强大的内存性能常用来作为系统提升的首选。Redis之于memcached算是后起之秀，redis具有更丰富的内容类型，并且每种类型都有自己的独有的计算方法，以计算偏向于数据的方式可以减轻客户端的压力，存储依然不够了怎么办，还有Redis-cluster。另一类Nosql数据库MongoDb我们常会用到类似于文档存储的场景。
3. 分布式数据库:在单机mysql达到极限的时候，这时候我们会考虑分库分表以支持数据的扩张，这也是一种分布式的数据存储方案。市面上针对不同的场景也有很多分布式数据库产品会用到，例如HDFS、FastDFS等，有时为了处理HDFS与sql之间的差异转换问题，可能会用到hive等产品。
4. 聚合数据库：当分库分表方案用尽了的时候，我们还能用什么？ES应该算是一种特殊的数据库，虽然他的出生主要是以聚合分析为主，通过倒排索引提高数据检索的速度，但是终究离不开数据的存储，所以也可以勉强把其归为数据库的一种。
   

消息中间件

分布式系统中解决不同系统之间通讯少不了的就是消息中间件。可以分为无代理消息架构与有代理消息架构。目前我们基本常用到的是有代理消息架构，类似产品RocketMq、Kafka、ActiveMq等。

分布式事务

分布式中最难解决的可能就是分布式事务，最终可能通过一系列柔性事务去解决最终一致性问题，牺牲性能以获得数据的准确性。目前比较或的一些框架有阿里的seata、gts等，或是通过业务上的一些手段例如XA、TCC、多阶段提交来解决。

分布式锁

分布式锁的实现方式主要有几种，1、基于mysql实现 2、基于zk实现 3、基于Redis实现 4、基于etcd实现

分布式ID

作用不多说，常用到的例如snowflake，美团的leaf也是基于此基础来的。

任务调度中心

一个分布式系统中我们需要由对定时任务进行批量管理，手动停止、启动、详情等的管理调度中心。例如xxl-job

配置中心

都分布式集群了，零散的配置肯定不能项目自己管理了。配置中心这时候就可以很好的维护起配置文件的作用。常用的apollo，spring cloud config

注册中心

在微服务架构里注册中心主要起到了协调者的一个作用；例如zookeeper、eureka

网关

作为流量的入口，统一的处理和业务相关的请求，让请求更加安全、快速和准确的得到处理。例如kong，spring zuul

服务监控

微服务系统一旦请求出现异常，我们必须得知道是在哪个服务环节出了故障，这样我们就需要对每一个服务，以及各个指标都进行全面的监控。我们常用到的会有 Prometheus，在这之前我们还用过zabbix、openfalcon等。

全链路跟踪

在微服务架构中，一个服务链路调用起来特别长，可能会涉及到多个服务，这时候查找问题需要全链路跟踪的出现了，我们叫他 APM系统。有Twitter开源的ZipKin，国内skywalking等都是优秀的组件。

熔断、降级、限流

熔断、降级、限流三个似乎总是一起出现，但是他们三个又都各司其职。熔断参考的生活中短路保护器的原理，当下游发生故障时，及时算开链路防止造成更大的影响，当它监控到调用下游的服务异常会根据策略进行适当的保护下游，采用防护下游系统的方式来间接保护自己被hang住太多超时的请求，他的策略有三种状态，全开、全断、半开状态。降级可以在熔断之后为服务自动触发降级以保护系统，同时我们也可以采用手动降级的方式，防止在服务熔断时再采取措施，这个方法很好用，大家记住。限流指的是限制达到系统的并发数量，限流的算法你至少应该知道 ：窗口、漏斗、令牌桶等等。

负载均衡

将流量转发到多个服务器来提高系统的可用性。可以分为三类，1、地域上的负载 DNS；2、硬件的负载 例如F5，做的是集群与集群间的负载；3、软件层面的负载，常用到的有nginx 和 lvs 分别工作在应用层 和 传输层 。

总觉得还有什么没说到

在一个大型的分布式系统中，我们还会用到 CDN 作为缓存动静分离使用，在lvs内部我们也应该知道VIP（虚拟IP技术）的原理和应用，同时我们还会考虑到Keepalived 和Haproxy作为系统高可用和负载的技术方案。

最后的最后

似乎总有用不完的手段，在整个水平扩展的架构再无新鲜之处外，正在逐渐火热的响应式异步编程正在慢慢燃起。我们可以使用Reactor编程模型去重构我们的系统，基于Reactive目前主要有几大框架，我们可以使用RxJava，Webflux等。目前springboot2.0之后主推的是webflux，受限于现在的JDBC等同步连接，我们可以使用netty进行一些改造，相信我们的系统单体性能可以提高几个数量级了。

似乎还有最后

技术一直在发展， 社会一直在进步，我们需要一直努力。总有人在创造，也总有人在生产，一堆堆的技术和方案其实都是为了解决现实问题而生。技术似乎不会有最后，总感觉还是有什么没有想到，希望和您一起聊下去。。。