一、架构本质思考
1.1、什么是架构？
1.2、架构就在生活中
假如你是食堂大妈，如何低成本解决高峰回收的阻塞？
假如你是车站保安，如何低成本解决春运进站的并发?
假如你是电工师傅，如何低成本解决异常电流的危害？
举例子如下：
二、业务架构方法论
2.1、战略驱动的顶层架构
2.2、战略设计 ( 子域划分)
为什么要分子域?
1、拆解难题: 通过领域的细分，逐步缩小问题域，降低业务理解和实现的复杂度。
2、区别对待: 区分不同子域功能的属性和重要性，投入不同的资源建设。
2.3、战术设计 ( 领域建模)
2.4、案例:仓储子域建模过程
三、系统架构方法论
3.1、系统拆分过程
3.2、系统演进过程
3.2.1、单体架构-应用服务器和数据库一个服务器
3.2.2、单体架构-应用服务器和数据库进行分离
3.2.3、引入本地和分布式缓存
3.2.4、Nginx 负载均衡
3.2.5、数据库读写分离
3.2.6、数据库按业务分库
3.2.7、大表拆分小表
3.2.8、多个 Nginx 负载均衡
3.2.9、DNS 机房负载均衡
3.2.10、NOSQL 和搜索引擎
3.2.11、拆分微服务
3.2.12、容器化技术
四、技术架构方法论
4.1、良好的技术架构应该是什么样子？
4.2、可靠性策略
4.2.1、分仓隔离---管控危机
解释: 让损失处于局部
举例: MQ 多个 topic，数据库防雪崩等，病毒的隔离区
原则: 减少故障的蔓延范围
4.2.2、冗余---狡兔三窟
解释: 冗余指的是多重保险，浪费是为了可靠
举例: 主备数据库，集群，异地多活等......
原则: 凡事和数据相关的应该保持双份
4.2.3、降级---断尾求生
解释: 丢车保帅，牺牲边缘功能，保全核心功能。
举例: 日志降级，风控降级，弱依赖降级......
原则: 在核心业务收到威胁的时候，如果非核心业务有拖累的情况，果断抛弃非核心业务。 !
4.2.4、兜底---最后屏障
解释: 最后的防护手段。
举例: 商场电梯防坠落网，走兜底逻辑，技术上也有很多类似的场景设计
4.2.5、回滚---原路撤退
解释: 善于用兵者给自己留下退路
举例: 发布应用，一定要留下可用版本，一旦线上有问题，可以回滚
原则: 好的架构师，任何时候都会留下退路
4.3、拓展性策略
4.3.1、解藕---井河无犯
解释: 由于性质有较大差异，不同的性质需要分开对待。同一个事物的两个或者
多个方面矛盾激化，以至于不可调和，通过分离来消除矛盾
举例: 前后端分离
原则: 业务 VS 数据、核心&非核心
4.3.2、异步---事件驱动
解释: 异步通过应答方主动提醒，释放了请求方的时间
举例: AIO，MQ
原则: 核心流程和非核心流程之间多用异步，降低了核心流程的风险
4.3.3、插件---随意组合
解释: 插件化的是为了更灵活的组合，适用变化
举例: 流程引擎
原则: 接口标准化
流程引擎: 业务流程的拓展，快速响应
规则引擎: 代替 IF- ELSE，可配置化
4.4、高性能策略
4.4.1、集群分进合击
解释: 集群就是众人拾柴火焰高，集群里面每个点都是微不足道，组合在一起就非常强大。
举例: 服务器集群
4.4.2、缓存未雨绸缪
解释: 把获取代价较大的资源提前准备好。
举例: 线程池、redis
原则: 遇到需要频繁实时用较大代价获取资源的情况，优先考虑缓存
4.4.3、并行多管齐下
解释: 并行的本质就是利用多块资源同时满足多件事情
举例: 一个功能里面多个查询逻辑，为了提高性能，可以并行查询
原则: 尽量将不必要的串行优化为并行
4.4.4、并发统筹方法
解释: 并发与并行的本质区别在于，并发存在资源竞争，本质上仍然是串行，只不过将资源利用效率提高
举例: 多线程
原则: 由于存在资源竞争，所以并发不是越多越好，每个系统根据自己的并发能力去设计
4.5、可维护性策略
4.5.1、监控及时感知
解释: 及早监控到已经发生的风险，并能预警
举例: 运维监控系统
原则: 1、核心服务要有操作记录和监控
2、监控到的风险及时预警
4.5.2、修复自我痊愈
解释: 在感知的基础上，系统能够自我恢复正常。
举例: 人体的免疫系统，能够自我修复。Dubbo 注册中心，断开重连，业务上失败重试（幂等）
原则: 自愈的前提是能够感知
4.6、安全性策略
4.6.1、脱敏/加密秘不示人
解释: 增加非相关人获取私密信息成本
举例: 项目采购招投标文件要转机需要密码解密操作，其他人不能看到
4.6.2、认证报上名来
解释: 你得让我相信你就是你，可是你凭什么说你就是你？
举例: Token，验证码，人脸识别。
原则: 认证前的唯一标识。
4.7、降成本策略
4.7.1、复用他山之石
解释: 整合一切资源，可以快速满足业务目标。
举例: 基础能力平台，组件库。
原则: 不要重复造轮子。
五、架构的表达方式
5.1、4+1 视图
5.2、架构设计原则
小结
本次主要介绍了 redis 在内存中使用的是简单动态字符串( SDS )，以及它的三种编码方式，还有它耗费内存的原因在于 RedisObject 和本身 SDS 的结构。我们可以使用压缩列表来节省内存，剖析了其节省内存的原因。并使用 Hash的数据结构给出了实际的节省内存的案例，大家可以根据实际的业务，合理的设计缓存的存储结构，达到节省内存的目的。这里可以推荐一个网址可以用来大致计算 Redis 的内存损耗redis内存损耗计算
参考
推荐阅读
招贤纳士
政采云技术团队（Zero），Base 杭州，一个富有激情和技术匠心精神的成长型团队。规模 500 人左右，在日常业务开发之外，还分别在云原生、区块链、人工智能、低代码平台、中间件、大数据、物料体系、工程平台、性能体验、可视化等领域进行技术探索和实践，推动并落地了一系列的内部技术产品，持续探索技术的新边界。此外，团队还纷纷投身社区建设，目前已经是 google flutter、scikit-learn、Apache Dubbo、Apache Rocketmq、Apache Pulsar、CNCF Dapr、Apache DolphinScheduler、alibaba Seata 等众多优秀开源社区的贡献者。
如果你想改变一直被事折腾，希望开始折腾事；如果你想改变一直被告诫需要多些想法，却无从破局；如果你想改变你有能力去做成那个结果，却不需要你；如果你想改变你想做成的事需要一个团队去支撑，但没你带人的位置；如果你想改变本来悟性不错，但总是有那一层窗户纸的模糊......如果你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的自己。如果你希望参与到随着业务腾飞的过程，亲手推动一个有着深入的业务理解、完善的技术体系、技术创造价值、影响力外溢的技术团队的成长过程，我觉得我们该聊聊。任何时间，等着你写点什么，发给 zcy-tc@cai-inc.com
微信公众号
文章同步发布，政采云技术团队公众号，欢迎关注
