http://jm.taobao.org/2016/12/23/20161223/
https://www.csdn.net/article/2015-02-10/2823900
https://daily.zhihu.com/story/4301040
淘宝架构网分享总结：
http://www.cnblogs.com/zhwl/p/3640883.html
使用一年ESB感受
https://www.cnblogs.com/welv/p/5411855.html
阿里ESB分享
https://wenku.baidu.com/view/364d2c4acf84b9d528ea7a52.html
微服务和SOA有什么区别？
SOA如果理解称为一种风格（面向服务）架构风格。那么微服务也是遵从这种风格。
而另一种理解就是IBM，SAP，DELL搞得SOA解决方案。比如ESB（企业服务总线），所有的服务通过企业服务总线来进行组织交互，比如一个事务通过好几个服务进行交互，那么就需要在ESB中注册WS-事务，ESB负责事务服务的编排和协议转换。
而微服务则是更去中心化的SOA，所有服务的所有环节，这里说的所有环节包括协议，业务，DB，都各自管理各自的了。每个服务各自负责各自的，关起门来自己玩，但是这样的话，服务的治理，服务的发现等周边工作就变得非常重要了。微服务的架构可以看成是康威定律的技术基础。
康威定律，设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。换句话说，团队的组织方式必然会对它产生的代码有影响。随着时间的推移，架构也会影响到团队的协作的好坏。当团队瓦解时，代码的交互就很糟糕。当团队协作时，架构就会集成的很好。
＝＝＝＝＝＝＝＝＝＝＝
服务网格和微服务有什么区别？
服务网格的职责，即处理服务间通讯，这正是服务治理的核心所在。边车模式是服务网格独创的，每一个服务实例，服务网格都会在同一个主机上面一对一部署一个边车进程，接管这个服务实例所有对外的网络通信。具体的服务不需要复杂对外如何提供服务，只需要关注业务，返回哪些数据。对于具体的服务交互和通信都是通过网格服务来完成。
＝＝＝＝＝＝＝＝＝＝＝
微服务分布式事务的一些思考
http://www.cnblogs.com/skyblog/p/4930015.html
微服务架构下的事务处理？
微服务架构下的事务就是分布式事务，尽量避免，如果避免不了，根据CAP理论“最终一致性”处理，如果处理了一些事务，还有可能出现数据错误，通过日志来找回数据，保证事务。
两阶段提交意思分为准备阶段和提交阶段，有一个事务协调者，给每个参与者发送准备消息，每个参与者在本地执行事务，但是不提交，或者发送失败的消息。当事务协调者收到失败消息，直接给每个发送者发送回滚消息，否则发送commit消息。
支付宝在分布式事务中设计了一套分布式事务框架，确保最终一致性。一个事务由一个主事务和多个从事务组成，主事务负责发起并完成整个业务活动。
＝＝＝＝＝＝＝＝＝＝＝
12306 系统在春运高峰期的稳定运行，采用了哪些具体技术？
https://www.zhihu.com/question/27321479/answer/37292320
从嗤之以鼻到“奇迹” 前淘宝工程师详解12306技术
http://network.51cto.com/art/201401/427406.htm
如何看待12306技术？
12306是一种动态库存的概念，它比淘宝更复杂，一个商品被买了之后，可能去掉了另外几个商品。
首先我们可以看看12306有哪些问题，首先是数据部署，大部分数据都部署在铁路的内部专网，而且票务数据都留在各个铁路局。所以早期的余票查询都会通过专有网络去各个铁路局查询，基本上把所有铁路局的票放在一个大池子里面，这个就是第一步要做的。
读写分离，买票其实很简单，但是读票就很难，把读票和写票进行分离，这个是非常有必要的。读票分离之后，可以使用云端的服务进行读票的操作，利用云的资源，比如CPU，内存等。现在已经是这么做了，在14年的时候。查票基本占网站流量90%以上。
前端优化加速。把所有的HTML，CSS，等提前加载好在本地，甚至可以包括有哪些列车，等信息。
多机房的容灾，数据在中国铁路总公司和研究院各有一套系统，作为安全备份。
带宽需要不断提升。网络购票的人越来越多。
＝＝＝＝＝＝＝＝＝＝＝＝
双十一背后的互联网技术
https://zhuanlan.zhihu.com/p/30968680
阿里P9资深架构师：支付宝和蚂蚁花呗的技术架构及双十一实践
https://zhuanlan.zhihu.com/p/34043808
阿里决战双11核心技术揭秘——混部调度助力云化战略再次突破
https://mp.weixin.qq.com/s/Ltu6AwvzKbo5R5e2dV_zJg
两地三中心／阿里巴巴高可用架构的演进史
https://blog.csdn.net/love_taylor/article/details/73603672
解密：几十万Docker容器如何撑起阿里双11
http://www.dajiangtai.com/community/18134.do?origin=csdn-blog
谈谈淘宝的双11？
阿里的技术每年都会经历双十一的考验，也是一次对所有部门所有升级技术的考试。
比如2017年，阿里提到的混部技术，将离线任务（伏羲），和在线实时业务（Pouch容器化改造）通过调度技术进行有机融合起来。将所有机器的利用率得到很高的提升。
比如2015年完成的异地多活技术，阿里也花费了3年时间搭建完成。之前淘宝还是使用业界比较流行的两地三中心的灾备方案。两地三中心的灾备方案就是第一个做了同城的双活，第二个做了异地的冷备。同城双活是实时在使用接收的，异地冷备是用来备份数据的。但是有几个问题，1 如果这个地方有灾难了，那么异地的要启动服务是很不靠谱的。2 异地冷备是异步的，延迟比较大 3 写必然是单点写，在写操作高的情况下有可能有问题。4 资源浪费，异地冷备的方案平时没有怎么使用。
异地多活，在多个地域都有数据中心，切所有数据中心都承担读写流量，并且写并不是集中到一个点，任意一个数据中心出问题，其他中心都可以分钟级别接管用户流量。其中数据同步是很大的问题，阿里开发了自己的分布式数据同步系统otter。在2015双十一，所有数据同步基本控制在1s以内。
虚拟化，阿里的linux内核是自己开发的，他们的虚拟化技术是基于docker开发优化的AliDocker技术。他们不仅把基础组建固化在Docker中，也推动把技术业务都固化到docker中，最终电商的所有核心应用都在docker中有多应用了。2017年双十一，几十万台Docker容器支撑起了交易17.5万每笔的峰值。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝
高并发时候的限流策略？
服务接口的流量控制策略：分流、降级、限流等
限流是下限策略，降低了服务接口的访问频率和并发量，换取服务接口和业务应用系统的高可用。
nginx限流，
在upstream的时候限流
也可以对一个ip连接数做限流
也可以限制每个ip每秒能请求多少次？
＝＝＝＝＝＝＝＝＝＝＝＝＝＝
高并发时候的降级策略？
降级有分为几种降级策略
一般来说读操作有很多降级的空间。比如我们最常用的是多级缓存模式。使用多级缓存来存放服务数据。当后端服务有问题，我们可以降级为只读缓存。
还有爬虫降级，我们可以在降级的时候拒绝一些互联网爬虫之类的请求抓取。
动态页面和静态页面的互相降级，页面原先需要经过动态接口请求的，降级的时候变为获取静态页面。原先是静态页面返回的，可以通过动态页面进行返回。
写操作我们其实也能降级。比如降级的时候我们使用缓存写，来让写操作统一写入到缓存中，最终使用异步同步的方式来进行同步，保证数据一致性。
降级开关的自动开关。首先并不是开关自动一定是好的，一般会设置自动和手动的。然后自动开关根据系统负载，资源使用情况，SLA等指标进行降级。
=====================
系统稳定性保障核武器——全链路压测
https://yq.aliyun.com/articles/163747
聊聊全链路压测？
在阿里2013年之前的压测都是拿线上的流量，做流量回放，流量录制等，对一台机器进行压力测试，获取单台机器的服务能力。但是这种情况和实际请求并不符合，单个系统ready并不代表了全局ready, 究其原因是由于系统之间的相互依赖和相互关联互相影响。所以获取单机的能力值是偏向乐观的。同时测试资源全部都集中在一些核心环节上，一些分散的业务并没有得到很好的压力测试。
阿里在2013年就开始研发核武器，全链路压测。全链路压测是使用不影响线上业务，但是数据与流量与线上业务隔离的生产环境。压测的基础数据，包括，压测用户，商铺，商品等基础数据。压测会根据不同场景，测试不同的压测量。
阿里最新的数据是全年，所有业务线自己的压测会达到10000+次，公司级别的大促业务压测能达到10+次。全链路压测已经是大促稳定性最重要的核武器了。