作为工程师，咱们一方面关注软件产品的能力和行为，这往往是一个我的项目的终点，另一方面咱们须要关注软件的架构设计，因为咱们心愿设计有着弹性、易于保护、高性能、高可用的零碎，更心愿零碎可能一直演进，而不是在将来被推倒重做。所以，回正咱们的视线，当咱们信心要设计一个好的架构时，咱们须要明确，架构往往决定的是软件的非功能性需要。这些非功能性需要有：

1. 易于开发：咱们心愿工程师一进入团队就能够立即开始进行研发工作，咱们心愿代码易于浏览与了解，同时开发环境足够简略对立。
2. 不便部署：如果零碎的部署老本很高，那应用价值就不会很高了，咱们很多企业都存在那种动也不敢动，改也不敢改，停也不敢停的零碎，除了祷告它别挂掉如同没有别的方法。拿到这样的零碎真的跟烫手的山芋一样，然而你还没得方法。
3. 易于运维：DevOps 的初衷是建设一种缩短运维与研发间隔的文化，让呈现问题后更容易解决，心愿让大家将视线放在产品上而不是限定本人的工种，这并不是冀望运维的同学可能成为 Java 专家，迅速的进行 heap 剖析发现问题，咱们强调的是运维时的闭环能力。
4. 保护老本：随着工夫的推移，给软件减少新性能就会变的越来越难，越是运行短暂的我的项目就会陷入重写还是重构的苦恼。往往危险在于批改代码会减少毁坏已有性能的危险，而且技术债也会越来越多难以偿还，即便是重写某些性能和模块，咱们也很难确定是否真的笼罩到了所有的性能，简而言之，don’t break anything 确实很难做到。
5. 演进能力：良好的架构设计应该能让零碎处于易于演进的状态，可能实现给飞驰的汽车换轮胎的能力，而不会被框架、底层的某种数据库、操作系统或者其余货色所绑架，然而这太难以做到了。确实，在我的项目进行技术选型时，因为某种数据库的个性而有偏向，然而在下层设计中，咱们必须保障不依赖于数据库的个性，而将应用这些个性的中央放到底层细节中。咱们也须要思考，不应用 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, 尽管易用性有所降落，但它反对海量数据及与编程语言无关的特色。

4. 任务调度 Job

任务调度 Job 如同数据库作业或 Windows 打算工作，是分布式系统中异步和批处理的要害。咱们的 Job 分为 WinJob 和 HttpJob: WinJob 是操作系统级别的定时工作，应用开源的框架 Quartz.NET 实现; 而 HttpJpob 则是自主研发实现的，采纳 URL 形式可定时调

5. 利用监控 Metrics

“没有度量就没有晋升”, 度量是改良优化的根底, 是做好一个零碎的前置条件。

6. 微服务框架 MSA

微服务是细粒度业务行为的重用，须要与业务能力及业务阶段相匹配。微服务框架是实现微服务及分布式架构的要害组件

7. 搜寻服务 Solr

分库分表后的关联查问，大段文本的含糊查问，这些要如何实现呢? 显然传统的数据库没有很好的解决办法，这时能够借助业余的检索工具。全文检索工具 Solr 不仅简略、易用、性能好，而且反对海量数据高并发，只需实现零碎两边数据的准实时或定时同步即可。

8. 更多工具

分布式协调器 ZooKeeper: 工作原理、配置核心、Master 选举、Demo。

ORM 框架: Dapper.NET 语法简略、运行速度快，与数据库无关，SQL 自主编写可控，是一款适宜互联网零碎的数据库拜访工具。

对象映射工具 EmitMapper 和 AutoMapper: EmitMapper 的性能较高, AutoMapper 的易用性较好。

IoC 框架: 管制反转 (IoC) 轻量级框架 Autofac。

DLL 包治理: 公司外部 DLL 包管理工具 NuGet, 可解决 DLL 集中存储、更新、援用、依赖的问题。

公布工具 Jenkins: - 键编译、公布、自动化测试、- - 键回滚，高效、便捷、故障率低。

注：波及的内容比拟多，因而只展现其中一部分，须要这份文档资料的，关注 + 转发后，私信“材料”即可查看获取形式

zookeeper

jenkins

单点登录

企业领取网关

第三局部：技术升级

单体问题

●单体利用，该合并的没有合并，该拆分的没有拆分，单个体量不合理，主平台体量太大，其余又过小。

●技术过旧: 应用 7 年以前的技术，主平台因采纳单体式架构，且体量过大，无奈整体更新保护。

●多版本共存: 版本凌乱，只敢增加，不敢批改。

●整个零碎十分软弱，问题多，访问量一大就“挂”。

●治理问题: 公布艰难，测试艰难，批改艰难，排错艰难。

技术改造：从单体利用到微服务

性能优化

上云纪要

技术与业务的匹配和交融

研发团队的倒退

 关注公众号：Java 架构师联盟，每日更新技术好文

局部材料曾经上传到我的 git 仓库中：有须要的能够下载

https://gitee.com/biwangsheng/mxq