这是我参与「第四届青训营 」笔记创作活动的第7天
今天我们主要谈一谈关于客户端架构和设计方面的知识。
先进行两个问题的引入
1.你所了解的架构是什么？
2.你觉得架构师们每天都在干什么？
答： 1.一个完美的设计，可以解决各种软件问题or没有完美的架构，需要不断地进行实现重构 2.每天根据用户的需求，讨论如何做软件设计or每天都在填坑，填不完的坑
架构所面临的问题
与此同时，不同技术领域面临的架构问题有明显的技术差异，但也有很多相似性。技术差异的部分，需要在一个领域长期积累才能有经验做技术设计和选型;相似的部分，是在长期积累之后抽象出来的部分，它是解决一类问题的方法论，从实践中来，最终也要落到实践中去。
此外，越来越复杂是客观规律，表现在:理解成本变高和预测难度变大。 认识到这个规律，我们就不要幻想简单架构来解决复杂问题，架构要做的是简约而不是简单，通过简单明了的约束来保障一致性，让大家好理解，好维护。 宏大的规模是不好理解的，譬如:在城市路网中容易迷路，但在乡村中就那么几条道，复杂的结构是不好理解的，譬如:一个钟表要比一条内裤难以理解，业务变化不可预测，譬如:头条一开始只是一个单端的咨询流产品，5年前谁也不会预先设计Lite版、抖音、懂车帝等，多端以及新的业务场景带来的变化是无 去预测的技术变化不可预测，髻如:作为一个java开发人员，Lambda表达式的简洁、函数式编程的快感、声明式(响应式U的体验，都是"真香的技术变化，而陈旧的Java版本以及配套的依赖都需要升级。
常见的架构手段
•不同架构手段的共同目标是高内聚低耦合
•找到适合业务场景的架构而不是炫技滥用
•一个复杂的系统是多种架构模型的组合体
架构演进的例子
•架构随业务发展由简单变得复杂是规律
•没必要最初用复杂架构来解决简单问题
•需要用规范持续重构来对抗代码的腐朽
一些比较大的架构手段
架构模型核心思路分层架构
- 将业务逻辑划分成若干层，每一层保持特定的角色，下层提供API给上层调用事件驱动架构
- 将业务逻辑抽象为事件的生产和消费，支持异步处理。是一种分布式架构模型，通常具备高扩展性和适应性微内核架构
- 将业务拆分为核心系统和插件，譬如:浏览器应用、各种IDE工具，都有一个宿主，并且支持扩展各种各样的插件微服务架构
- 将业务拆分为多个独立的服务单元，通过服务注册和发现机制，多个服务可以互相调用，单个服务的下线，不会导致整个系统崩溃。
