大型网站架构特征：
1.高并发？（用户访问量比较大）
解决方案:拆分系统、服务化、消息中间件、缓存、并发化
高并发设计原则
系统设计不仅需要考虑实现业务功能，还要保证系统高并发、高可用、高可靠等。同时还应考虑系统容量规划（流量、容量等）、SLA指定（吞吐量、响应时间、可用性、降级方案等）、监控报警（机器负载、响应时间、可用率等）、应急预案（容灾、降级、限流、隔离、切流量、可回滚等）。
拆分系统
在我们从零开始做一个新系统的时候，会首先进行系统功能模块架构设计，那么是直接做一个大而全的垂直的MVC系统，使用一个war包进行发布管理，还是需要按一些规则进行模块拆分，设计成SOA或者微服务系统比较好呢？这个笔者认为需要依据项目具有什么样的人力物力条件以及项目需要支撑多少用户量和交易量为基础。一个好的系统设计应该能够满足解决当前的需求和问题，把控实现和进度风险，预测和规划未来，避免过度设计，在上线一个基础核心版本之后，再进行不断迭代和完善。
今天我们来谈一谈进行SOA、微服务系统架构设计时模块拆分的一些维度和原则。
系统维度：按照系统功能、业务拆分，如、优惠券、购物车，结算，订单等系统。
功能维度：对系统功能在做细粒度拆分，优惠券系统分为 优惠券后台系统、领券系统、发券系统。
读写维度：比如商品系统中，如果查询量比较大，可以单独分为两个服务，分别为查询服务和写服务,
读写比例特征拆分；读多，可考虑多级缓存；写多，可考虑分库分表.
AOP 维度： 根据访问特征，按照 AOP 进行拆分，比如商品详情页可分为 CDN、页面渲染系统，CDN 就是一个 AOP 系统
模块维度：对整体代码结构划分 Web、Service、DAO
服务化
在分布式系统中，将业务逻辑层封装成接口形式，暴露给其他系统调用，那么这个接口我们可以理解为叫做服务。
当服务越来越多的时候，就会需要用到服务治理，那么会用到Dubbo、SpringCloud服务治理框架
后续在深入Dubbo和SpringCloud中会详细讲到。
服务化演进: 进程内服务-单机远程服务-集群手动注册服务-自动注册和发现服务-服务的分组、隔离、路由-服务治理
考虑服务分组、隔离、限流、黑白名单、超时、重试机制、路由、故障补偿等
实践：利用 Nginx、HaProxy、LVS 等实现负载均衡，ZooKeeper、Consul 等实现自动注册和发现服务
消息队列
消息中间件是一个客户端与服务器异步通讯框架，消息中间件中分为点对点与发布订阅通讯方式，生产者发送消息后，消费者可以无需等待， 异步接受生产者发送消息。
在电商系统中，会使用消息队列异步推送消息，注意消息失败重试幂等性问题。
幂等性问题解决方案，使用持久化日志+全局id记录。
缓存技术
浏览器端缓存
APP客户端缓存
CDN(Content Delivery Network)缓存
接入层缓存
应用层缓存
分布式缓存
对于兜底数据或者异常数据，不应该让其缓存，否则用户会在很长一段时间里看到这些数据。
并发化
改串行为并行。
2.高可用？（在高并发 保证系统不被宕机）
解决方案:降级、限流、切流量、可回滚
高可用设计原则
通过负载均衡和反向代理实现分流。
通过限流保护服务免受雪崩之灾。
通过降级实现部分可用、有损服务。
通过隔离实现故障隔离。
通过合理设置的超时与重试机制避免请求堆积造成雪崩。
通过回滚机制快速修复错误版本。
降级
对于高可用服务，很重要的一个设计就是降级开关，在设计降级开关时，主要依据如下思路：
1.开关集中化管理：通过推送机制把开关推送到各个应用。
2.可降级的多级读服务：比如服务调用降级为只读本地缓存、只读分布式缓存、只读默认降级数据（如库存状态默认有货）。
3.开关前置化：如架构是Nginx–>tomcat，可以将开关前置到Nginx接入层，在Nginx层做开关，请求流量回源后端应用或者只是一小部分流量回源。
4.业务降级：当高并发流量来袭，在电商系统大促设计时保障用户能下单、能支付是核心要求，并保障数据最终一致性即可。这样就可以把一些同步调用改成异步调用，优先处理高优先级数据或特殊特征的数据，合理分配进入系统的流量，以保障系统可用。
限流
目的: 防止恶意请求攻击或超出系统峰值
实践：
恶意请求流量只访问到 Cache
穿透后端应用的流量使用 Nginx 的 limit 处理
恶意 IP 使用 Nginx Deny 策略或者 iptables 拒绝
切流量
目的：屏蔽故障机器
实践:
DNS: 更改域名解析入口，如 DNSPOD 可以添加备用 IP，正常 IP 故障时，会自主切换到备用地址; 生效实践较慢
HttpDNS: 为了绕过运营商 LocalDNS 实现的精准流量调度
LVS/HaProxy/Nginx: 摘除故障节点
可回滚
发布版本失败时可随时快速回退到上一个稳定版本
3.网站演变过程
单体架构 ->分布式架构 ->SOA(面向服务架构-面向于业务逻辑层) ->微服务
单体架构
SSH、SSM 分层结构开发 (传统项目)
分布式架构
将一个项目进行拆分，拆分成n多个子项目 (根据业务逻辑拆分)
比如电商系统。拆分为优惠券系统、订单系统、支付系统、消息系统、交易系统，最终要将所有拆分的子项目整成一个流程，通过域名跳转访问。
SOA
面向服务架构 ，业务逻辑和试图展示层分离。
涉及到RPC远程调用技术（Dubbo、SpringCloud）
将业务逻辑层抽取出来，封装成服务(接口)，给其他的子系统调用。
SOAP=http+xml格式
ESB （消息总线）
微服务
基于SOA演变过来，继承了SOA优点，去除了SOA层ESB消息总线，采用http+json(restful)
微服务架构与SOA区别
1微服务架构基于SOA演变过来，继承SOA优点微服务架构中去除SOA架构中的ESB消息总线，采用http+json（restful）。
2.微服务架构比SOA架构粒度会更加精细，让专业的人去做专业的事情（专注），目的提高效率，每个服务于服务之间互不影响，微服务架构中，每个服务必须独立部署，互不影响，微服务架构更加轻巧，轻量级。
3.SOA架构中可能数据库存储会发生共享，微服务强调独每个服务都是单独数据库，保证每个服务于服务之间互不影响。
4.体现项目特征：微服务架构比SOA架构更加适合与互联网公司敏捷开发、快速迭代版本，因为粒度非常精细。