前言
最近公司在组织系统分析的相关培训，整个培训的目的是提升产研的系分能力（说的不好听就是让你干更多活（小声BB
）），今天就抽一些时间把最近的内容分享给各位小伙伴。
上周刚刚有大佬分享了应用架构的相关内容，我一直觉得不想做的架构师的码农，不是一个合格的段子手，架构这块应该也算是应用设计中特别重要的内容，而且好的系统架构可以让系统更稳定，bug更少，系统运行成本更低，所以本着这样的目标，我又把大佬上课的ppt好好梳理了下，算是对这块内容的回顾和小结。
应用框架
定义
-
应用框架定义了系统由哪些应用组成，以及应用之间如何分工和合作
-
应用作为独立可部署的单元，为系统划分提供了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面
-
应用架构拆分方式：
-
水平拆分：按照功能处理顺序划分应用，比如 web前端、中间服务、后台任务，这是面向业务深度的划分 -
垂直拆分：按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分 -
应用的合反映应用之间如何协作，共同完成复杂的业务，主要体现在应用之间的通信机制和数据格式。
-
通信机制：同步调用、异步消息、共享 DB访问 -
数据格式：文本、 xml、JSON、二进制等 -
应用的分偏向业务，反应业务架构，应用的合偏向于技术，影响技术架构
-
在应用架构设计过程中，应用的分降低了业务复杂度，使系统更有序，应用的合增加了技术复杂度，系统更无序
-
应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散
-
应用架构设计的初衷是为了减少应用程序之间的关系，让系统内部程序实现松耦合
架构分解
架构依赖
依赖稳定部分
-
稳定部分不依赖易变部分； -
易变部分可依赖稳定部分； -
要求：避免循环依赖
核心服务依赖
-
核心服务不依赖分核心服务 -
非核心服务可依赖核心服务； -
要求：核心服务稳定
基本服务依赖
-
基本服务不可以向上依赖聚合服务； -
聚合服务（内容聚合、流程聚合）向下依赖基本服务； -
要求：基本服务稳定
非功能性服务依赖
-
非功能性服务不可依赖功能性服务 -
功能性服务可依赖非功能性服务 -
要求：非功能性服务稳定
平台服务依赖
-
平台服务不依赖上层应用； -
上层应用可依赖平台服务； -
要求：平台服务稳定
跨域弱依赖
-
跨业务域调用时，尽量异步调用，弱依赖
服务设计
独立性
-
提供最小粒度的业务功能 -
服务层面的独立性：服务间的界限清晰，但服务也可能共享基础资源 -
纯粹的独立性：服务拥有并控制基本逻辑
无状态
可复用
-
复用粒度是有业务逻辑的抽象服务，不是服务实现细节； -
服务引用只依赖服务抽象
可治理
-
服务治理契约：可降级、可限流、可开关、可监控、黑白名单机制
松耦合
-
跨业务域调用，尽量异步调用； -
必须同步调用时，设置超时时间和队列大小 -
稳定的基本服务与易变的聚合服务分层
基本服务设计
-
基本服务下沉、可复用：如商品、库存、价格等 -
基本服务的实现要求精简，可水平扩展 -
基本服务自治，相互独立 -
基本服务实现物理隔离，包括集成服务相关的数据
应用设计实践
-
在应用架构设计过程中，主要考虑如下内容： -
子系统划分：依据架构分解原则，对概念结构阶段设计的系统进行分解； -
接口定义：明确各子系统、各模块之间的接口定义； -
交互机制：明确各子系统、各模块之间的交互机制，如基于接口编程、消息机制或者 RPC调用等
架构图
-
在进行应用架构设计时，应该根据系统的复杂性进行合理的拆分、组合，然后针对不同的部分，分别进行描述； -
对于简单的系统，如系统内部少量的子系统、模块构成，并且与外围系统交互比较少，甚至无交互，则建议在一张应用架构图上表现整体系统的组件、接口和交互机制。 -
对于复杂的系统，如系统由多个子系统组成。每个子系统由多个模块组成，并且每个子系统单独开发、测试、部署，这些子系统之间通过某种交互机制进行通讯，协作完成指定的功能集，服务于用户。另外，这些子系统需要与其他已经存在的系统进行通信，则： -
针对这样的系统，建议通过多张应用架构视图分别展示每个子系统的组件、接口和交互机制，以及该子系统与其他子系统的交互机制。此时，其他子系统以黑盒的方式存在，不必细化其内部组成 -
在每张应用架构视图内部，如果涉及的组件比较多，并且存在比较复杂的组件，建议架构视图展示组件的应用架构设计； -
对于子系统之间或者子系统与其他系统的交互机制，如果简单、明确，则直接在应用架构视图中展示。如果比较复杂，则单独使用一张交互机制图进行补充说明
结语
严格来说，我觉得以上的这些内容只能算是一个check list（大佬当时也是这么说的），也就是协助我们分析当前系统架构是否合理的一个检查清单，有了这样一个清单我们可以清楚系统架构的改造优化方向，当然如果是一个新的系统的话，这样的清单可以帮助我们厘清系统架构思路，确保最终架构的合理性。
最后，我想说的是，单靠几堂课、几本书，你大概这辈子都当不上架构师了，因为这个世界上真的是实践出真知，你只有熟悉各类组件、各类框架以及各类架构模型，然后经过了无数次的实践论证，那才叫真正的架构成功，所以铁子们学起来吧，因为：
– END –
原文始发于微信公众号（云中志）：架构笔记 | 初探架构基础
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/128951.html
