如何选择合适的架构
分类: Azure云架构师入门 ◆ 标签: #Azure #基础 #Azure Cloud Architecting ◆ 发布于: 2023-06-05 11:27:33
对于大型系统的设计，架构师这个角色必不可少，架构师除了要对系统有足够深入的了解，同时也需要对业务有深入的了解，架构师的职责之一就是要根据业务的需求，选择合适该业务场景的应用架构，保证应用架构的可扩展性以及可维护性，以及可实施性。一个应用系统实施的好坏和架构师有着非常紧密的关系。
那么架构师在选择应用架构时首先需要了解目前成熟的架构有哪些，并且要熟知各种架构的优点，缺点，限制。
目前流行且得到过验证的架构有如下几种：
- N层架构：N层架构非常适合传统企业向现代云架构转换的迁移架构。优缺点都非常明显，更新发布慢。
- Web-消息队列-辅助计算： 这个架构非常适合小型的企业以及应用，主要的技术点时使用消息队列解耦前端和计算，优缺点也非常明显。
- 微服务架构：今年对于大型的应用采用较多的架构，技术难度很高，确实符合多团队，大项目的架构。
- 事件驱动架构：采用消费-订阅(或者生产消费架构), 对于实时系统，低延时系统非常有帮助。
- 大数据/大计算架构: 主要用于非常专业的领域，例如机器学习,AI, 数据分析，仿真等业务场景。
需要理解的是当你采用某一种架构样式来解决某个问题，在使用这个架构的时候，要严格的落实这个结构的一些基本准则，而且这些准则约束了你能够采用的技术形式，Azure服务及组件的选择，团队的招募和培训，项目开发的流程管理以及部署管理等等。关于这个部分也需要充分理解约束即规则，规则也会限制未来的扩展等一些列的事宜，这是一把双刃剑。
不同的架构样式合适不同的业务领域，这个也是非常需要注意的，例如N层架构更适合传统的，更新频率低的领域，微服务更适合大型，混合型业务领域，更新频繁，但是监控管理问题定位是一个大难题。
对比一下各个架构适合的业务领域
| 架构样式 | 依赖项管理 | 业务领域 |
|---|---|---|
| N 层 | 按子网划分的水平层 | 传统的业务领域, 更新频率较低。 |
| Web-队列-辅助角色 | 通过异步消息传送分离的前端和后端作业。 | 包含一些资源密集型任务的相对简单域。 |
| 微服务 | 通过 API 相互调用的垂直（功能）分解服务。 | 复杂业务。 频繁更新。 |
| 事件驱动的架构 | 生成者/使用者。 为每个子系统提供独立视图。 | IoT 和实时系统 |
| 大数据 | 将巨型数据集划分为小区块。 针对本地数据集执行并行处理。批处理和实时数据分析。 | 使用机器学习进行预测分析。 |
| 大计算 | 将数据分配到数千个核心。 | 仿真等计算密集型域。 |
我们上面讨论了架构的约束一把双刃剑，云架构师需要考虑：
- 架构的复杂性
- 异步消息传送以及最终的一致性
- 服务之间的通讯
- 客观理性。
我们后面会每一个架构样式进行更细致的学习，同时记住上述的原则。