来自一线大厂架构师，分析分析亿万级架构系列，（师傅领进门，修行靠个人）

适合人群：

刚入行的小白--多了解一下工具的使用

有多年开发经验菜鸟--针对某些点，可以深入理解

有10+的老鸟--可以共同学习，一起提高

一，痛点/难点

1， 熟悉业务及需求

2，实时性/及时性/延迟少

3，稳定性/高可用/易扩展

4，数据量大存储问题/查询问题/一致性问题/迁移问题

5，组件的选型/架构的前瞻性/投入成本

6，接口防爬虫/防攻击

7，监控/性能优化/满足变更需求

二，问题分析

1，分析熟悉业务及需求

1.1 离开业务谈架构，一般都是瞎扯，没有最好的架构，只有更适合的架构，所以业务才是首位。就像redis集群一样，讲究的是耗时短，低延迟，而放弃了强一致性，只能做到最终一致性。一个系统无法全部满足CAP要素， 只有找到满足需求的架构，才是最好的架构。

2 分析实时性/及时性/延迟少

2.1 对实时性要求高，低延迟的都需要使用缓存，组件缓存一般有redis/couchbase/pika/elasticsearch等，另外还有本地内存，共享内存，磁盘等，实时性强的缓存是必须的。

2.2 实时性要求高，也可以使用mq之类的解偶掉，是系统成为异步系统，可以实时返回。

3，分析稳定性/高可用/易扩展

3.1 首先需要保证程序稳定，避免程序带来的一些问题

3.1.1 程序挂掉的情况，如内存越界，空/野指针，多次释放，并发等问题，避免措施：1）若是c++程序，则输出coredump文件，使用gdb分析问题，修改代码。 2）若是go程序，则直接查看日志Panic定位，修改问题。

3.1.2 防止内存泄露，内存使用遵循哪里申请哪里释放原则。一般只有需要手动管理内存的语言才会出现，如C++，可以使用valgrind工具分析。若是go程序出现内存大，导致内系统OOM掉，可以使用pprof工具分析内存使用情况。

3.1.3 死锁，遵循最小化原则，一般根据现象及代码排查，难度相对较高。但go的话一般会抛出系统错误，容易排查

3.1.4 代码检查，自动化检查及review方式，golang的自动化检测可以使用golangci-lint。写代码易忽略点：1）注意优雅退出。2）高内聚低耦合

3.1.5 使用工具管理程序重启，关闭，可以自动拉活，如supervisor

3.2 考虑不稳定性，使得系统高可用

3.2.1 考虑程序的不稳定性，天下没有无bug的程序，当一个程序挂掉不会影响整个系统运行，就像nginx的upstream的server挂掉一台，依然可以正常的分流到其他server上。云上的可以使用LB。

3.2.2 考虑中间件的不稳定性，即使使用成熟的中间件也可能存在问题，比如redis集群，也可能出现脑裂问题，需要增加降级处理方案。

3.2.3 考虑基础设施的不稳定性，机器有可能硬件故障，系统崩溃等，另外也有可能断网，断电等众多不稳定因素，这就设计到架构的设计方面，每个重要节点都不能是单点模式。

3.2.4 爬虫及攻击，网络是复杂多变的，暴露的接口地址，可能会遭到爬虫带来的性能损耗，也有可能被攻击，更有可能整个机房都遭受攻击（ddos/ssdp），使得业务无法正常工作，影响客户使用。可以使用过滤器，过滤掉爬虫，另外不暴露不必要的端口信息，搭建多机房接口或者可以购买阿里云腾讯云防护服务避免攻击带来的影响。

3.3 易扩展

3.3.1 垂直扩展，一般可以从业务上分开，就像深圳到北京一样，有高铁，有飞机。若运输能力还不行的话，可以增加轮船。系统亦如此。

3.3.2 水平扩展，一个业务可以增加并行处理方式提高速度。如上深圳到北京的例子，高铁运输能力不足，可以增加多个高铁站，并发运输。

4，数据量大存储问题/查询问题/一致性问题/迁移问题

4.1 大数据量存储

4.2 大数据量查询

三，案例实践

四，总结