点赞不容易的架构师
架构师，分基础架构和业务架构。做业务项目，自然是接触业务架构师比较多。一般业务会划分多领域，每个领域都有自己的架构师，确保自己所属的系统能满足系统定位和架构演进。每个项目一般只有一个主导架构师，最终对外一个声音。当然，架构师还有一个职责，在扯皮的时候也会找到他们，系统边界其实有时候并不是那么容易确定，他们也挺不容易，虽然工资比较高。
今天，我重点跟大家分享下我所看到的架构方案涉及的主要内容。它一般会包括项目背景、项目目标、业务流程、系统整体架构等内容。
项目背景：业务诉求是什么，为什么有这个诉求，怎样满足这个诉求。
项目目标：解决业务痛点，提升系统运行质量。可能是升级或替换现有架构，确保架构在满足业务诉求的同时，可靠可扩展。
业务流程：业务全流程梳理（售前、售中、售后等，从底层数据、到中间聚合、到上层应用适配、到前端）、目标系统的业务定位（是否需要打造新的系统或服务支持，与现有系统的分工是怎样，提供哪些服务，核心改造各系统与上下游业务系统关系绝对需要弄清楚）。很多场景架构会说到统一性：统一入口、统一界面、统一登录、统一权限控制、统一工作流，要统一其实并不容易。
系统整体架构：分层架构—系统展示层、业务层、聚合服务层、基本服务层、资源层（数据库、缓存、文件系统、网络等），辅之以基础组件，比如消息传递组件、监控组件、任务调度组件、日志管理系统、权限管理系统、安全风控系统等。
很多架构师在这一步都会详细说明：哪些系统需要新增，哪些需要调整，哪些保持不变—需要新增哪些服务、需要调整哪些服务。这就说明间接各系统的改动点，这都建立在业务系统充分了解的基础之上的。
这里可能主导的架构师会搞几个方案，让大家探讨。当然，他会有自己联系方案，可能也会包括短期长期方案，通常这与不同开发团队负责人和架构师内部讨论得到的结果，对外声音一致确实很重要。
系统服务交互：从底层数据到综合计算，赋能下游业务，通过接口实时或通过数坊表离线赋能，最终生成可视化报表。具体细节—上下游系统交互、表结构、数据字典、数据模型、重点关键场景说明、交互流程图、时序图、输入输出等。
业务保障体系：业务场景、规则完善、数据交互、性能优化、业务监控完善、系统自动修复机制、日志完善等。
潜在问题分析：异步同步调用、修改后关系同步、重试兜底方案、增加数据同步、统一数据源、数据一致性、缓存治理、远程异地备份复活、避重就轻。
架构师不是完美的，架构也不是一开始就完美的，我相信大部分架构输出都是通过各方面信息收集整合、结合行业做法、内部多次理解讨论的结果。技术方案有他的身影，画饼有他们的身影，扯皮有他们的身影，他，无处不在，甚至影响很多人很多年。这个角色，和项目经理一样，其实应该是个纯粹的工作，把不清晰的地方弄清晰，在领导的关怀和支持下，一定会做得非常好的。
附给自己看到的头条内容，调整平时说话的方式，让人看到你的正能量：
—把“嗯嗯”，换成“没问题”
—把“随便”，换成“听你的”
—把“无所谓”，换成“我ok的”
—把“听懂了吗”，换成“我说明白了吗”
—把“我不会”，换成“我可以学”
—把“我不知道”，换成“我马上了解”
—把“你不行”，换成“你再努力下”
—把“我好烦”，换成“我需要冷静”
—把“我怎么知道”，换成“这个我也不太明白”
网友评论