阿里内部是如何进行架构设计？内部参考文档流出，你该这样准备

作者: java架构师联盟 | 来源:发表于2020-07-28 13:16 被阅读0次

作为工程师，我们一方面关注软件产品的能力和行为，这往往是一个项目的起点，另一方面我们需要关注软件的架构设计，因为我们希望设计有着弹性、易于维护、高性能、高可用的系统，更希望系统能够不断演进，而不是在未来被推倒重做。所以，回正我们的视野，当我们决心要设计一个好的架构时，我们需要明确，架构往往决定的是软件的非功能性需求。这些非功能性需求有：

易于开发：我们希望工程师一进入团队就可以立刻开始进行研发工作，我们希望代码易于阅读与理解，同时开发环境足够简单统一。

方便部署：如果系统的部署成本很高，那使用价值就不会很高了，我们很多企业都存在那种动也不敢动，改也不敢改，停也不敢停的系统，除了祈祷它别挂掉好像没有别的办法。拿到这样的系统真的跟烫手的山芋一样，但是你还没得办法。

易于运维：DevOps 的初衷是建立一种缩短运维与研发距离的文化，让出现问题后更容易处理，希望让大家将视野放在产品上而不是限定自己的工种，这并不是期望运维的同学能够成为 Java 专家，迅速的进行 heap 分析发现问题，我们强调的是运维时的闭环能力。

维护成本：随着时间的推移，给软件增加新功能就会变的越来越难，越是运行长久的项目就会陷入重写还是重构的苦恼。往往风险在于修改代码会增加破坏已有功能的风险，而且技术债也会越来越多难以偿还，即使是重写某些功能和模块，我们也很难确定是否真的覆盖到了所有的功能，简而言之，don't break anything 的确很难做到。

演进能力：良好的架构设计应该能让系统处于易于演进的状态，能够实现给飞驰的汽车换轮胎的能力，而不会被框架、底层的某种数据库、操作系统或者其他东西所绑架，但是这太难以做到了。的确，在项目进行技术选型时，因为某种数据库的特性而有倾向，但是在上层设计中，我们必须保证不依赖于数据库的特性，而将使用这些特性的地方放到底层细节中。我们也需要考虑，不使用 Spring 提供的 Dependency Injection，我们该如何组织我们的 beans，也要考虑将来系统的前端是 web 还是 mobile 还是都要支持？

所以当这一些问题我们都想兼顾的时候，在于进行架构设计的时候考虑的有多细，资源有多雄厚，那些动辄亿级流量或者超大型研发团队，确实能够解决这些问题，就像这次疫情的钉钉，虽然流量的疯狂涌入，但是，瞬间，后台阿里云开通更多的资源容纳这一部分冲击，所以，外界看来，几乎没什么影响，但是，能这样操作的企业又有几家呢？基本都是资源用在刀刃上，那该怎么办呢？互联网巨头阿里出了一份参考手册，共分为三部分

第一部分：企业架构

如果说运维是地基，那么框架就是承重墙。盖房子是先打地基，再建承重墙，最后才垒砖，所以中间件的搭建和引进是建设高可用、高性能、易扩展、可伸缩的大中型系统的前提。所以，一个好的架构设计关系到后期整个项目的稳重

第二部分：技术理解

需要这份文档资料的，关注+转发后，私信“资料”即可查看获取方式

1.集中式缓存Redis

缓存是计算机的难题之一.，分布式缓存亦是如此。Redis 看起来非常简单，但它影响系统的效率、性能和数据一致性。用好它不容易，包括缓存时长(复杂多维度的计算)、缓存失效处理(主动更新)、缓存键(Hash和方便人工干预)、缓存内容及数据结构的选择、缓存雪崩的处理、缓存穿透的处理等。Redis 除了缓存的功能，还有其他功能，比如Lua计算能力、Limit 与Session 时间窗口、分布式锁等。我们使用SericeStack.Redis做客户端，使用方法详见Demo。

2.消息队列RabbitMQ

消息队列好比葛洲坝，有大量数据的堆积能力，再可靠地进行异步输出。它是EDA事件驱动架构的核心，也是CQRS同步数据的关键。为什么选择RabbitMQ而没有选择Kafka?是因为业务系统对消息有高可靠性要求,以及对复杂功能(如消息确认)的要求。

3.集中式日志ELK

日志主要分为系统日志和应用日志两类。试想一下，如何在- -个具有几百台服务器的集群中定位问题?如何追踪每天产生的几GB甚至几TB的数据?集中式日志就是此类问题的解决方案。早期我们使用自主研发的Log4Net+MongoDB来收集和检索日志信息，但随着数据量的增加，查询速度却变得越来越慢。后期改为开源的ELK,虽然易用性有所下降，但它支持海量数据及与编程语言无关的特征。