×
ABao阿宝
想是问题,做是答案;输在犹豫,赢在行动。
阿里巴巴中台战略思想与架构实战读书笔记
分类:
学习笔记
发表:2020-05-17
围观(2196)
抢沙发
一、打造平台稳定性能力 1、限流和降级:超过服务处理上线则启动限流,指标是QPS,最优的限流拦截点在前端接入层面。域名类限流、cookie限流、黑名单以及一些安全策略。使用Spring AOP可以实现限流。 2、单机、局部问题带来的影响: 2.1、分布式服务环境调用链路局部问题会被放大到整个链路 2.2、单点、局部问题会被放大成面。 3、流量调度采集的信息 3.1、系统指标信息:CPU、Load 3.2、业务指标信息:HTTP响应时间、QPS、服务调用响应时间、Tomcat线程池使用信息 4、业务开关:修改程序中static值来达到业务逻辑切换。(可实现自动化Apollo) 5、容量压测及评估归回 6、全链路压测平台:自助化 6.1、基础数据抽取:线上数据采样、过滤和脱敏 6.2、链路与模型构造:链路范围、链路的访问量级、链路的参数集合、基础数据的特性一起构造了压测的业务模型。 6.3、链路验证 6.4、业务改造 6.5、数据平台 6.6、流量平台 6.7、影子表:避免污染到线上数据 6.8、中间件改造 6.9、安全机制:第一层是安全的监控和保护,建立非法流量的监控机制,正常用户访问不了测试数据,测试也无法访问线上。第二层是对测试流量的安全过滤。 7、业务一致性平台:业务逻辑指定操作规则,在触发的时候,异步检查,若有问题,则及时报警,告知系统研发工程师或者运维工程师。 二、服务怎么拆? 这和企业大了,必须划分部门是一个道理。有4大原则: 1、高内聚,低耦合 2、数据完整性 3、业务可运营性 4、建设渐进性 总之,就是责任划分的比较清楚,每个中心规模相当。 面向中台的服务中心,就是要把共享服务划分好,比如客户中心,订单中心等等。 但,同时又不能拆分的过细,比如会员数据如果跟客户中心高度相关,按照数据完整性的原则,就不应单独拆分出来。 三、数据怎么拆? 数据库就像图书管理员,但你的藏书规模不大的时候,一个管理员就能应付过来了;但是如果你管理的书籍和资料非常大的时候,管理员就成了瓶颈,这个时候,就需要增加人手。 当有多名管理员的时候,你可能会让张三负责小说,李四负责社科,王五负责自然科学。这是基于业务划分的原则。 但是,马上发现张三忙的要死,李四闲的要死,为了避免这种情况,就需要采用随机的方法划分数据。 过了一段时间又发现有一些热门的书籍,比如小说,借阅的人非常多,因此你会多买几套,找专人管理起来,提高效率。对数据而言,小说就相当于热数据,因此就复制一份放到内存里面,以提高访问效率。 四、业务怎么拆? 在IOE时代,写应用的一项重要工作是保障事务的一致性,这需要数据库加锁来保障。在服务中心化之后,一次交易就涉及跨中心了,如果还靠数据库来保障事务一致性,明显不现实。所以,就需要用很多软件的办法来解决事务一致性的问题。 一是把大事务拆小,分阶段异步完成。在这种思路下需要在业务层面来协调分阶段提交的关系。有的事务部涉及主流程,比如下发通知信息等,就直接剥离;有些小事务可以用反向的业务来考虑,而不是事务回滚,比如退货以后,进行退款,而不是取消之前的交易。同时要可以增加交易校验机制和增加资源预占以及两阶段提交。 二是引入柔性事务的概念,即交易最终的状态保持一致,在这个过程中,容忍一定程度上的不一致,换来高可用性。比如数据库锁比较豪资源,那么采取软件方式实现无锁,可以有效提升资源效率,但需要牺牲一定的交易过程中的用户体验。同时还可引入日志和补偿机制,从更底层来保障事务一致。 另外有些分布式系统的新问题,需要考虑的,比如机器和机器之间的通信,消息可能会丢,所以要考虑采用可靠消息传递机制,远程模块之间一定要用异步消息来驱动。
标签:
阿里巴巴
读书笔记
中台
本文
暂无
评论
回复给
点击这里取消回复。
验证码(*)
Top
Python
产品设计
学习笔记
网络基础
PHP
经营管理
运维开发
系统测试
Shell
Java
系统开发
Linux运维
运维架构
Go
×
本文 暂无 评论