什么是架构

架构概念很大，根据软件研发的一般生命周期来看，主要有业务架构、应用架构、技术架构、部署架构，架构人员需要全程主导这个过程，完成系统的总体架构落地，具体来看各个阶段的架构工作侧重点有所差异，同时相互联系。

业务架构：

来源于业务需求，涉及需求治理，其与项目管理密不可分，主要管理模式有传统瀑布式（需求文档驱动）、精益敏捷式（专题故事驱动），需求分析最终产出业务架构，架构人员参与该过程，对接业务人员对需求进行分门别类，整理清楚各个业务范围的关联关系，做到引导和满足业务人员合理诉求，同时以架构人员的经验设计扩展性预留，具体操作上可以使用DDD（领域驱动）方法论进行操作，该阶段架构人员的产出相关的业务架构图，颗粒度上达到业务模块比较合适。
本阶段的难点在于业务诉求中的不合理、不清楚以及业务人员没想到的业务点，作为架构人员需要引导、识别及补充，最终帮助业务人员实现业务价值的书面化体现、系统化的转化以及业务实施规划的落地，甚至需要能满足业务人员的汇报诉求。

应用架构：

根据业务架构设计，结合现有的基础设施、中间件、存储方案及数据流向，设计出应用的多层架构图，这部分是最重要，也是最复杂的，对于每个层，在复杂场景下，各个层内部还需要再进行架构设计，比如存储层是否需要做读写分离，是否需要做多级存储，接入层是否需要做限流、安全设计，前端展示层是否需要做缓存、CDN加速等等。
应用架构设计还需要识别出本系统相关交互外系统的接口、交互方式、数据规范等问题并进行设计解决。
本阶段的难点在于对业务架构的理解程度及对业务发展的预判，需要有业务行业经验及技术实战经验，同时对公司现有运维保障能力、技术中间件的成熟程度有充分的把握。

技术架构：

相比应用架构，技术架构的侧重点在于解决应用层相关设计的技术实现问题，需要分两个层面来看，第一整体的技术栈，比如做服务化是在用SpringCloud全家桶还是用Dubbo，用SpringCloud使用Spring cloud Alibaba 还是 Spring cloud Netflix，这个根据团队的技术栈进行匹配，架构师需要主导这个部分的架构选型，过程可以进行评审，综合各方面的实际情况，推荐阿里李运华的《从零开始学架构》书中分享的案例操作方式，选出风险小的、能满足现阶段的方案进行演进。第二方面，对于局部性的技术架构，比如需要做多级缓存又不想做的太复杂，自研组件方式的，需要专门来做技术方案，可以有架构师或者高级技术人员来设计及实现，这部分可以可能有比较多的，需要对影响比较大进行技术架构阶段评审去确定，对于功能级别的设计可以放到项目实施过程中详细设计阶段进行。
本阶段的难点是架构人员技术广度和深度，对技术方案表达能力、演讲能力，以及高级技术人员的方案的指导评审能力。