准备PPT过程中的一些文档记录

时间:2024-09-04 08:07:43

http://jm.taobao.org/2016/12/23/20161223/

https://www.****.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.****.net/love_taylor/article/details/73603672

解密:几十万Docker容器如何撑起阿里双11
http://www.dajiangtai.com/community/18134.do?origin=****-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+次。全链路压测已经是大促稳定性最重要的核武器了。