1，拆分
拆分是为了降低系统的复杂度，模块或服务“自治”，符合软件设计中“单一职责”原则。拆分的太粗或者太细都会有问题，这里没有什么标准答案。应该按照领域拆分，结合业务复杂程度、团队规模等实际情况来判断。可以想象5个人的小团队去维护超过30多个系统，那一定是很痛苦的;
2、隔离
拆分本质上也是一种系统级、数据库级的隔离。此外，在应用内部也可以使用线程池隔离等。分清“主、次”，找出“高风险”的并做好隔离，可以降低发生的机率。
服务器级别隔离，比如我们需要考虑为VIP建设单独的服务器集群，甚至是IDC网络接入；服务级别隔离，为重要的业务线单独分配并且路由到单独的虚拟机或POD，为大文件上传的服务进行服务拆分部署到具有更高IO和网络带宽的服务器上；进程内部进行资源隔离，比如在使用Java 8 ParallelStream的时候考虑采用单独的线程池来处理任务，比如在使用Netty处理较慢的业务操作的时候配置单独的业务线程池进行处理，和IO处理的线程池进行隔离。
3、冗余
避免单点，容量冗余。机房是否单点，硬件是否单点，应用部署是否单点，数据库部署是否单点，链路是否单点…硬件和软件都是不可靠的，冗余（“备胎”）是高可用保障的常规手段;
4、异步化
尽可能的异步化，尽可能的降低依赖。异步化某种程度可以提升性能，降低RT，还能减少直接依赖，是常用的手段;
使用线程池来进行异步处理一些非关键的任务，使用MQ进行异步处理。比如下单的主流程就是落地和发MQ通知其它模块，落地后后续出库、物流的流转全部是其它模块在收到MQ消息后异步处理的。
极端一点例子，对于一些用户行为数据分析平台需要接收客户端上传的各种事件进行分析，如何可以抗住100万TPS的并发进行处理？最简单的方式就是直接搞10台Nginx负载均衡，Nginx只是记录AccessLog返回200（单机抗住10万TPS一点不是问题），后续由定时任务拉取AccessLog进行数据分析。
5、合并请求
每一个独立的网络请求都是开销，我们可以通过合并动态静态的请求来减少请求数量。现在的Web前端应用基本都会在构件打包阶段对脚本、CSS进行压缩合并等预处理。
对于后端动态请求而言，我们更需要在设计阶段考虑接口的粒度，并且区分对待实时处理和批处理的架构，数据批处理的工作不太适合通过循环调用远程接口的方式实现。
6、边缘加速
CDN就是边缘加速的一个例子，一般而言我们使用CDN不仅仅为了让用户访问数据更快，而且通过在边缘节点做一定的缓存策略可以让节点帮我们挡住很大部分的流量（特别是静态资源，除了回源的请求都可以由CDN挡掉）。
更进一步说，一些CDN可以做一些定制化的处理，允许业务方提供一些简单的脚本在节点做边缘计算，比如在秒杀场景下根据一定的策略直接在CDN节点进行计算，放行0.1%的用户流量进入我们的后端系统。
内容分发网络，部署在网络运营商机房，通过将静态页面内容分发到离用户最近的CDN 服务器，使用户可以通过最短路径获取内容。
7、空间换时间
缓存
一种是在程序启动的时候从外部数据源初始化大量的不怎么变的数据到内存中，在内存中形成面向搜索友好的数据结构（比如哈希表），提供快速的数据访问，之后所有的请求都无需请求数据源，采用定时拉取或监听变动消息的方式同步变动。
另外一种是利用分布式缓存做计算结果的缓存，具有比较短的过期时间，可以挡掉大量重复请求，对于搜索条件组合较多的请求命中率差。当然，缓存除了使用空间换时间之外，一般还会利用存储介质的性能差异来提升性能，所以我们看到通过内存缓存数据比较常见。
缓冲
对非时间敏感的调用进行适当蓄水，甚至合并，一次性提交到后端服务，比如玩一个抓红包的游戏，用户在屏幕上点点点来抓红包，是否真的有必要每次都向数据库更新红包余额呢？
可以在服务端缓冲一下，10次更新一次余额甚至整个游戏只提交一次？
8、面向数据读取优化
比如微博的实现在发微博的时候找出大V下一定数量的活跃的在线粉丝，比如5000个，直接把微博写入他们的关注微博列表中去（推数据过去），这样在那些粉丝刷新自己微博首页的时候就能更快（不用去关联拉数据了）。
又比如许多时候我们会做所谓的固化视图的工作，在写入数据的时候就直接写为我们之后要读取的复杂数据结构（比如数据需要Join N个表才能获得的，在写入的时候就直接组成这样的数据写到数据表）。
或者可以说我们做哈希结构，做B树索引，做倒排索引都是这样的思路，使用一些有利于我们之后读取、查询和搜索的数据结构来加速数据的读取（虽然写入的时候耗时多一点，并且需要占用额外的空间）。
或者预测到将来用户可能会访问的请求，进行预加载或是预处理，然后之后真正请求到来的时候这个访问就会特别快。
9、任务并行化
可以把多个子任务提交到线程池执行，然后等待所有任务都完成后进行结果汇总，这样总的耗费时间就是最慢的那个子任务的执行时间。
10、负载均衡
将多台应用服务器组成一个集群，通过负载均衡技术将用户请求分发到不同的服务器上，以应对大量用户同时访问时产生的高并发负载压力。
负载均衡的策略，Backend健康检测，服务失效后从负载均衡摘除，恢复后的上线，发布系统和负载均衡的联动。比如有上万台服务需要负载，那么可能需要10组Nginx来做负载均衡，这10组Nginx本身也需要进行负载均衡，那么可以在最上层使用硬件F5或Haproxy在4层再做一层负载，也就是类似主备Haproxy->Nginx集群->tomcat集群类似的架构。
11、分区处理
指的是把数据、任务进行分区，分发到不同的节点同时处理，提高并行度。数据表的分表分库，然后由类似Proxy的中间件进行数据路由和汇总处理；比如Java 8 parallelStream的思想把数据分成多份在不同的线程同时处理；比如ConcurrentHashMap锁分段的思想，把全局的锁改为分段锁减少冲突；比如kafka的分区处理扩展等。
12、限流
任何系统对于压力的负荷是有边界的，超过这个边界之后系统的SLA肯定无法满足标准，导致大家都无法好好用这个服务。计数器算法、令牌桶、漏桶。
13、降级
是否可以考虑降级为客户端这边之前写死的一些静态的活动商品列表；在外部地图API访问超时的时候需要考虑降级方案，把骑行距离改为根据经纬度算出来的直线距离，至少让服务基本可用。
14、熔断
一个客户端可能会依赖几十个其它的服务，有任何一个位于同步调用的外部服务出现超时，即使客户端的ReadTimeOut设置的时间不长也对客户端是很大的压力和负担。
根据请求失败率熔断，比如在一定时间内有一定百分比的请求是失败的，那么就开启熔断；
根据响应时间熔断，比如一定时间内的请求平均响应时间超过N秒则开启熔断。
在外部服务遇到问题的时候要自动进行熔断，在外部服务恢复后尝试半恢复，最后完全恢复访问。
15、柔性化
在电商订单的场景中，下单，扣库存，支付是一定要执行的步骤，如果失败则订单失败。但是加积分，发货，售后是可以柔性处理，就算出错也可以通过日志报警让人工去检查，没必要为加积分损失整个下单的可用性。
16、静态化
对于访问量特别大而更新又不很频繁的动态页面，可以将其静态化，即生成一个静态页面，利用静态页面的优化手段加速用户访问，如反向代理、CDN、 浏览器缓存等。
静态资源，如JS,CSS 等文件部署在专门的服务器集群上，和Web 应用动态内容服务分离，并使用专门的（二级）域名。
17、浏览器优化
通过优化响应页面，加快浏览器页面的加载和显示，常用的有页面缓存、合并HTTP 减少请求次数、使用页面压缩等。合并CSS,合并JavaScript,合并图片，设置HTTP 头中Cache-Control 和Expires 的属性，可设定浏览器缓存，缓存时间可以是数天，甚至是几个月；CSS 放在页面最上面、JavaScript 放在页面最下面。
以上总结了普通的几点，下面附上比较收藏比较经典干货的文章：
1， 双十一大型电商统一服务架构实战 https://mp.weixin.qq.com/s/n8G-E61iQttpBSBjN07zZQ
2，这次咱们从根源聊：16招搞定高并发架构设计 https://m.sohu.com/a/320224240_411876/?_trans_=010005_pcwzywxewmsm&from=timeline
3，架构 | 大型网站分布式高并发架构设计汇总 https://mp.weixin.qq.com/s/3niKVzeW_g-a60QTIjbRpQ
4，为了做到微服务的高可用，鬼知道我出了多少张牌 https://mp.weixin.qq.com/s/8g-C6Li0FohMqKF-IN1vlQ
5，阿里为啥值4万亿？看它如何应对亿级高并发大流量？如何保障高可用和稳定性，就知道了！ https://mp.weixin.qq.com/s/eDlu8f99NfdBqt-OPFqb_A
6，披荆斩棘，饿了么数据库高可用架构演进！ https://mp.weixin.qq.com/s/ezjugOU473aLuEegk3Eryg
7，亿级PV，常见性能优化策略总结与真实案例 https://mp.weixin.qq.com/s/npnikNTvrxusePmmhjeuFw
8，从订单业务模块到分布式高可用：美团外卖订单中心的演进之路 https://mp.weixin.qq.com/s/CxXzo1-hveKLqI4nFsSsFg
9，分布式架构－－基本思想汇总 https://mp.weixin.qq.com/s/pu9lrWZQvDAVzYG1LuBE9w
10，大型分布式网站架构技术总结 https://mp.weixin.qq.com/s/71UG1gJK_I81MIEg7D1HEg
11，支付平台架构评审 https://mp.weixin.qq.com/s/OES3aD6V-M40u6FjZb9Qsg
12，架构师眼中的高并发架构 https://mp.weixin.qq.com/s/CeUFUwVctTbQ50fBuPcydQ
13，盘点电商大战背后的技术力量支撑 https://mp.weixin.qq.com/s/B5TqW0o_atz3PfgMxhj3CQ
14，详解：淘宝大秒杀系统是如何设计的？ https://mp.weixin.qq.com/s/SV-FHtxTxKIK9CyHsWuDYA
15，性能优化指南 https://mp.weixin.qq.com/s/Ok_jyuLdn6IxXa8wk1crbQ
16，大型网站技术架构：摘要与读书笔记 https://mp.weixin.qq.com/s/g9Js_sd-vhQSNh20YbLypQ
17，构建高并发高可用的电商平台架构实践 https://mp.weixin.qq.com/s/spZpmt3wDVz9BPUlzNDRzQ
18，秒杀系统架构分析与实战，一文带你搞懂秒杀架构！ https://mp.weixin.qq.com/s/x3JIxNfCOfIF7GAn9rFMAA
19，各大互联网公司架构演进之路差不多都在这了 https://mp.weixin.qq.com/s/rBwAWOF9da4yCUKy23eEnA
20，手把手教你从零开始搭建创业公司后台技术栈 https://mp.weixin.qq.com/s/D6CSEklDkhNMZ_BvkK5UoA