您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识
怎样成为IT架构师？
架构,架构师,技术怎样成为IT架构师？
发布时间：2016-12-08加入收藏来源：互联网点击：
怎样成为IT架构师？
回答于 2019-09-11 08:43:50
回答于 2019-09-11 08:43:50
架构师是整个软件工程和软件生命周期里面相当重要的一个角色，介于软件需求和开发之间的一个承上启下的关键角色，即能够实现业务需求和场景到最终软件实现的第一次高度抽象建模。在更早的阶段一般会谈系统分析员角色，那么这个角色往往会同时兼顾软件需求和软件架构的工作。
软件架构简单来说就是将业务或软件需求进行高度抽象，形成静态和动态的模型，通过形式化的模型来表达和阐述真实的业务需求。同时这个抽象化的模型又能够很好的指导后续的开发实现。
软件架构要做三个方面的工作：
第一：针对软件需求中的业务场景和流程，功能性需求进行功能性架构设计，其中包括了核心的功能架构设计，子系统和模块的划分，接口和集成模式的设计，数据架构和数据模型的设计等。即通过概念模型，类图或数据库设计等静态模型+用例，序列图等动态模型共同来抽象表达出完整的业务需求。
第二：通过软件需求中的非功能性需求，来考虑整个系统的技术架构设计，技术架构本身又包括了类似消息，缓存，安全，日志等关键技术的实现，也包括了IT基础设施和部署架构的设计，同时还包括了类似高可用，高可靠，高性能，高扩展等非功能性需求满足的架构设计。
第三：对于软件生命周期和软件工程域标准内容的设计，其中包括了开发框架，技术选型，软件生命周期，持续集成模式，架构标准规范，开发规范，测试规范，以及各种架构规约和约束等方面的内容设计。同时还需要基于上面内容进行相应的架构原型搭建和验证工作，确保架构设计内容能够真正落地。
要能够做好上面三方面的内容，一个真正架构师必须既懂技术又懂业务，而对于当前很多互联网应用，由于本身工作相对细分，可以看到很多架构师往往仅仅只需要专研深核心技术领域的技术和某一垂直业务场景即可。在这点上企业内部信息化架构师和互联网本身还是存在区别，企业内部架构师更加强调业务+技术综合能力。
架构设计的核心目的是全面的理解业务需求后给出整体的技术方案，避免后续在开发实现中遗漏。架构设计内容不仅仅是指导后续的详细设计和开发，同时更加重要的是通过组件和划分和接口的设计，让后续的开发工作真正能够并行起来，最终再进行集成，以降低软件研发的复杂度，同时又缩短软件开发周期提升效率。
能够把一个复杂的大系统真正想清楚和透彻，同时还能够把大系统拆散为松耦合的多个模块，最终又在各个模块独立并行完成开发后，能够通过预先定义的接口将这些模块又组装和集成起来，这就是一个真正架构师应该做的事情。我们也可以看到，一个好的建筑工程师往往就具备如上能力。
技术最终是解决业务问题和为业务服务，也正是整个原因，一个好的架构师不应该陷入到技术驱动，而是业务驱动；不是选择最新，最热的技术或框架，而是应该选择当前最合适的技术和框架。架构师应该避免过度设计和技术狂热，而是真正做好业务和技术的适配，成本和收益的分析工作。
胸有成竹，那么一定是自己已经画过无数次的竹子，也正是这个原因架构师往往都是从一线技术开发多年的实践积累后组建锻炼出来的，好的架构师一定来源于实践而非理论，只有这样既保证了架构设计的高屋建瓴，又确保了最终的架构设计能够真正落地。长期脱离实践的架构师往往很容易犯经验主义错误，设计出空中楼阁式的架构，看起来完美，实质上却虚于表面。
架构师应该具备的架构思维
对于架构思维本身仍然是类似系统思维，结构化思维，编程思维等诸多思维模式的一个合集。由于架构的核心作用是在业务现实世界和抽象的IT实现之间建立起一道桥梁，因此架构思维最核心的就是要理解到业务驱动技术，技术为最终的业务服务。
因此要真正通过架构设计来完成业务和技术，需求和实现，软件和硬件，静态和动态，成本和收益等多方面的平衡。
分解是最基础的，架构的重点就是要对复杂问题进行分而治之，同时保证分解后的各个部分还能够高内聚，松耦合，最终又集成为一个完整的整体。分解核心是定义问题，因此架构首先仍然需要理解清楚需求。
集成是配合分解完成的动作，最终分解完成的各个组件或子系统，通过合适的接口设计，最终还能够集成为一个完整的整体，分解仅仅是加速开发和降低问题复杂度，如果分解后的内容无法集成在一起，那么分解就没有任何意义。分解+集成可以理解为架构最核心的思考方式和方法。
动态+静态：一直是我强调的重要思维模式，架构思考里面一定要注意这两者的结合，即涉及到流程，用例等动态分析内容，又涉及到数据，类等静态建模内容，而是两者要高度协作起来完成整个架构思考。
复用是另外一个重要的思维，也可以理解为SOA参考架构的核心思考模式，包括最近谈的最多的业务能力组件化，组件能力服务化，平台+应用，共享中心建设，共性能力下沉等都是谈的复用的概念。及时你架构设计一个小系统，你也需要将各个模块需要用的共性功能抽取为可复用的共性组件。
分层相对重要，架构在设计中要考虑分层，而核心仍然是资源+服务+应用的三大层，分为这三层仍然是SOA参考架构的核心思想。对于平台+应用更多只是上面分层模式的一个变形。分层的目的是通过分层既理清了整个应用的构建过程，又保证了各层之间的独立设计和松耦合。
模式匹配：可以讲是所有思维模式里面的一个重点，而架构设计中的模式匹配就是要将最终的业务域问题匹配到对应的技术实现上面。即根据业务需求来挑选最适合的技术，而不是用主流和最先进的技术去反推业务。
抽象是架构思维里面的一个重点，这里面包括了两个层面的内容，一个是常说的归纳方法，即各种类似场景的实现见的太多了，自然就归纳了一个规则或方法出来供以后的设计用。但是抽象更加重要，即将非类似场景中的共性内容也总结出来，进一步抽象为类似的东西，以更加方便的适应变更和各种变化。
结构化思维是架构思维必须具备的，最常用的两种结构就是二维的表格和树模型，通过结构化思维引入了维度和XY概念后，可以帮助我们更好的分析和比对，结构化决策等。对于多维模型，我们也要有意识的将其转换为多个平面二维模型，方便我们进行分析。
迭代思维是架构思考中需要考虑的另外一个内容，没有最优的架构，只有不断进化的架构，只有最适合的架构。因此架构本身也在随着业务需求的变化不算的迭代和演化，而不是追求用最新的技术一步到位。
最后即我们常说的系统思维，系统思维是架构思维中最重要的思维模式，一个架构师必须要有充分的全局思考的能力，做好前面谈到各种平衡，追求整体的最优化而不是单个目标的最优。
下一篇：返回列表
相关链接 |
||
| 网友回复（共有 0 条回复） |