阿里巴巴中台战略思想与架构实战读书笔记-学习笔记-ABao阿宝

阿里巴巴中台战略思想与架构实战读书笔记

分类：学习笔记
发表：2020-05-17
围观(582)
抢沙发

<a href="" title="" target="_blank"></a>一、打造平台稳定性能力

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、建设渐进性

总之，就是责任划分的比较清楚，每个中心规模相当。
面向<a href="https://www.xubaojin.com/tags-744.html" title="中台" target="_blank">中台</a>的服务中心，就是要把共享服务划分好，比如客户中心，订单中心等等。
但，同时又不能拆分的过细，比如会员数据如果跟客户中心高度相关，按照数据完整性的原则，就不应单独拆分出来。

三、数据怎么拆？

数据库就像图书管理员，但你的藏书规模不大的时候，一个管理员就能应付过来了；但是如果你管理的书籍和资料非常大的时候，管理员就成了瓶颈，这个时候，就需要增加人手。
当有多名管理员的时候，你可能会让张三负责小说，李四负责社科，王五负责自然科学。这是基于业务划分的原则。

但是，马上发现张三忙的要死，李四闲的要死，为了避免这种情况，就需要采用随机的方法划分数据。

过了一段时间又发现有一些热门的书籍，比如小说，借阅的人非常多，因此你会多买几套，找专人管理起来，提高效率。对数据而言，小说就相当于热数据，因此就复制一份放到内存里面，以提高访问效率。

四、业务怎么拆？

在IOE时代，写应用的一项重要工作是保障事务的一致性，这需要数据库加锁来保障。在服务中心化之后，一次交易就涉及跨中心了，如果还靠数据库来保障事务一致性，明显不现实。所以，就需要用很多软件的办法来解决事务一致性的问题。

一是把大事务拆小，分阶段异步完成。在这种思路下需要在业务层面来协调分阶段提交的关系。有的事务部涉及主流程，比如下发通知信息等，就直接剥离；有些小事务可以用反向的业务来考虑，而不是事务回滚，比如退货以后，进行退款，而不是取消之前的交易。同时要可以增加交易校验机制和增加资源预占以及两阶段提交。

二是引入柔性事务的概念，即交易最终的状态保持一致，在这个过程中，容忍一定程度上的不一致，换来高可用性。比如数据库锁比较豪资源，那么采取软件方式实现无锁，可以有效提升资源效率，但需要牺牲一定的交易过程中的用户体验。同时还可引入日志和补偿机制，从更底层来保障事务一致。

另外有些分布式系统的新问题，需要考虑的，比如机器和机器之间的通信，消息可能会丢，所以要考虑采用可靠消息传递机制，远程模块之间一定要用异步消息来驱动。

标签：

阿里巴巴

读书笔记

中台

ABao阿宝

天道酬勤，厚积薄发。

本文暂无评论

回复给点击这里取消回复。

ABao阿宝

天道酬勤，厚积薄发。

本文 暂无 评论

回复给 点击这里取消回复。

本文暂无评论

回复给点击这里取消回复。