《程序员必读之软件架构》

Part I 什么是软件架构

    第1章 什么是架构

  

本文通过拆解了解软件架构是什么，架构和设计的区别，敏捷的架构意味着什么，以及为什么思考软件架构很重要。

在不同人的眼里面“架构”一词的意思大相径庭，互联网上对架构的定义也多如牛毛。如果你问身边人大概得到的结果如下：

  模块、连接、依赖和接口

 大局观

 改变成本很高的事情

难以改变的事情

更加兼顾全局的设计

接口而非实现

审美（比如：艺术一般的整洁代码）

概念模型； 满足非功能需求/质量属性；每件事都有“架构”；计划；一定程度的严格和可靠性；蓝图；系统、子系统、交互和接口；

管理；战略决策的产出；必要的约束；结构（组件和交互）；技术方向；战略和愿景；结构单元；实现目标的过程；标准和准则；

整个系统；工具和方法；从需求到产品的道路；指导原则；技术领导力；构成产品的元素之间的关系；对环境约束和限制的意识；基础；

抽象的观点；把问题化整为零的过程；产品的骨架、支柱；

     通过上面的词 的描述，感觉放之四海皆准；很多方面都可以用的上。从上面一系列词的区分可以区分动词和名字

  1.1作为名词

    架构做为名词来解释时，概括起来都与结构有关：将产品分解为一系列组件、模块、和交互。这需要考虑整个产品，包括处理（建筑物）供电、供水、空调，或处理

 （软件的）安全、配置、错误处理等横切关注点的基础设施服务。

 1.2 作为动词

架构作为动词来解释时，包括了理解你需要构建什么、设定愿景以便于进行构建和做出恰当的设计决策。所有这些都要以需求为基础，因为需求驱动架构。关键在于，架构是关于交流愿景以及引入技术领导力的，这样参与构建产品的每个人都能理解这个愿景，并为产品的成功做出积极的贡献。

     第2章 架构的种类

1.功能架构

2.应用架构

3.数据设计

4.物理架构

5.顶层架构规划

6.网站功能规划

7.应用规划

8.SOA规划

9.分层架构

10.数据库规划

     第3章 软件架构是什么

       应用程序架构

          这个应该是我们开发人员接触 的最多的 。应用程序架构 的关注点 是应用程序，通常包括将应用程序结构为类和组件，确保设计模式的正确使用，构建或使用框架等。

   应用程序架构谈论的是软件设计的低级别切面。结构单元主要以软件为基础，包括编程语言和结构、类库、API等。应用程序架构着重考虑软件和组织代码。

    

         系统架构

             和应用程序架构相比，规模更大的应用程序架构。大多数软件系统实际上是由横跨不同层次和技术的多个应用程序组成。

               现在最基本的 都是前后端分离， H5端由VUE，nodejs等组成独立的应用，然后通过接口请求服务端API，服务端 通过经典的 三层  Controller ,服务层，持久层（数据库层）。

           从 用户访问入手， H5端请求 Server端API，然后 再结合  缓存中间件，消息队列，数据库，和 elk 等组成一个完整的系统。

          要让整个软件系统工作起来，就要思考如何组合这些单独的应用程序。换句话说，要有端到端软件系统在较高层次上的整体结构。另外，大多数软件系统都不是孤立的，因此系统架构还关注互操作性和与环境中其他系统的集成。结构单元就是各种软硬件，从编程语言和软件框架到服务器和基础设置。和应用程序相比，系统架构描述为从组建和服务器到子系统等更高层次的抽象。系统架构的定义大多都包含了软件和硬件。

        此图是从网络拷贝过来的。

 

          软件架构

           软件架构 就是 应用程序和系统架构的结合。

          从代码结构和基础到将代码成功部署到生成环境，与一个软件系统重要元素相关的所有东西就是软件架构。从开发者的角度考虑软件开发，关注点多数会放在代码上。在这里，我们考虑的是有助于架构更好软件的东西，比如面向对象的原则、类、接口、控制反转，重构，自动化单元测试，代码整洁度等。

        例如：

         横切关注点， 安全性，包括认证，授权和敏感的数据保密，性能，可伸缩性，可用性和其他质量属性；审计以及其他监管要求；客观环境的约束；交互操作性；

   与其他系统的集成；运营、支持和维护的需求；结构和整个代码库的解决问题、实现特性的方法的一致性。

     评估正在构建的基础有助于交付按计划进行。

       设计阶段要远离代码和开发工具，对软件的整体视角可以确保你的代码符合整体愿景而非背道而驰。

    企业架构：战略而非代码

       这个才是整个组织最核心的的工作，公司的价值就在于如何组织和利用人员、流程和技术来使企业有效和高效的工作。它是关于企业如何分成组或部门。业务流程如何在上层运作，以及技术和如何支撑这一切。这根软件架构形成了强烈的对比，因为企业架构没有必要关注技术细节。相反，企业架构可能看重的是如何在整个组织中最后的利用技术，而无需实际介入这些这些技术的工作原理。

    现在都是扁平化架构，都划分为各个BP 也就是事业部。 一个事业部有自己的业务线，可以独立核算。这个是关乎到公司能否存活的，能否在市场的竞争中保持存活的。

       有些开发者和软件架构师把企业架构看做职业发展的下一站，然而大多数人却并非如此。从事企业架构工作所需要的思维方式和软件架构大相径庭，对于技术以及在组织中的应用，视角很不一样企业架构需要更高层次的抽象。这关乎广度而非深度，关乎战略而非代码。

     第4章 敏捷软件架构是什么

          敏捷开发也不是什么新的词了，这个在软件开发中主要是指软件开发的敏捷方法；快速行动，拥抱变化，持续交付，接收反馈，不一而足。

          其实软件开发人员经常最怕的是需求变动，一天一个想法，但是现实中的事情往往是瞬息万变的。人们如何在敏捷环境中一起工作，通常包括了团队动态、系统思维、心理学以及其他可能会跟创建高效团队联系在一起的事情。

说一句大白话，敏捷的意思是能时刻应对环境中的变化，适应人们不断提出的变化的需求。这个和敏捷团队创建的软件架构不尽相同。以敏捷方式交付软件并不能保证得到软件架构是敏捷的。这个结果往往是相反的，很多开发人员往往是疲于应付交付过来的任务，而在原有的项目基础上 在看似合适的地方，加上“合适”的代码。通常没有通用性和扩展性。

敏捷 到底是什么东西呢？想知道结果，得先看看它的来源。

其实我们现在很多软件的思想都是来自美国军方的项目，例如我们用的互联网，最初是用来处理雷达监听的。同样的，这个敏捷，也是美国空军战斗员提出的一个名为OODA循环的概念。这个循环构成了基本的决策过程。想象一下，你是一个正在与敌人缠身的战斗员，为了击败对手，你需要观察情况，确定自己的访问，决定做什么，并最终采取行动。在瞬息万变的战场上，这个循环过程要做到最快。你先做完这个循环，也意味着你的反应快，更可能称为最后的赢家。

同样的，这个思想运用到软件开发中，就得出结论敏捷是相对的，且按照时间来衡量的。如果你的软件团队交付的软件根不上所处环境的变化，就不算敏捷。如果你在一个庞大而行动缓慢、鲜有改变的组织中工作，很可能交付软件要花费数月，却仍然被认为是“敏捷的”。在一个精益创业的初创团队中，情况多半就不一样了。

好的架构带来敏捷，但是任何事情都有双面性，我们要做的最多的情况是根据目前手头的资源，时间，和人力来选择走哪一套方法。

 

软件架构的角色

    要称为一名软件架构师，绝非一夜之间或者一次晋升那么简单。这是一个角色，而非一个级别。这是一个循序渐进的过程。你会逐渐获得这个角色所需要的经验和信心。

“软件开发者”这个词很容易理解，而“软件架构师”则不然。

    架构驱动力

      理解目标；抓住、提炼、挑战需求和限制

     设计软件   

     建立技术和战略、愿景和路线图

     技术风险

      发现、减轻和承担技术风险，保证架构的运转

      架构演化

     贯穿整个软件交付过程，持续的技术领导和对架构的承担。

    编写代码

    参与到软件交付的实践部分

    质量保证

    引入并坚持标准、指导、原则等