文章目录
1. 什么是软件架构2. 架构的分类3. 软件架构演变过程3.1单体架构(all in one)3.1.1优点3.1.2缺点 3.2分布式架构(垂直架构)3.2.1特点3.2.2优点：3.2.3缺点： 3.3SOA架构3.3.1特点3.3.2优点3.3.3缺点 3.4微服务架构3.4.1特点3.4.2优点3.4.3缺点3.4.3缺点1. 什么是软件架构
单体项目的尴尬之处：当项目中的某个模块的使用人数激增，例如618当天，下单的人数一定会非常多，但是因为下单和评论、售后是同一个项目，会导致下单卡顿的同时，评论和售后也会一起卡顿。
于是乎，就有了微服务的概念。每个项目可以理解为只完成特定的模块功能，比如刚才的下单和评论、售后、就可以分开三个项目。
软件架构是一个系统的草图。
软件架构描述的对象是直接构成系统的抽象组件。
各个组件之间的连接则明确和相对细致地描述组件之间的通讯。
在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。
在面向对象领域中，组件之间的连接通常用接口来实现。
总结成一句话，软件架构是对一个系统进行宏观上的设计。
其实软件架构非常类似于建筑设计规划，城市总体规划等，其实就是架构，只是应用的场景不同。盖一座小房子，可以拍脑袋干起来，但是当你要盖一座大楼，如果没有一个建筑设计规划，可以想象搭建最后是什么样？打个比方，在建造一个桥梁之前，需要先由桥梁工程师先对桥梁进行整体设计，比如说整个桥梁由哪些组件构成，组件和组件如何结合到一起，各个组件使用什么材质，整个桥梁可以抗多少级地震，多少级台风，多少吨承重，这些都属于架构。
2. 架构的分类
架构可以分为：业务架构、应用架构、数据架构和技术架构，整体逻辑关系如下：
业务（逻辑）架构：使用一套方法论对产品（项目）所涉及到的需求的业务进行业务边界划分，简单的讲就是根据一套逻辑思路进行业务的拆分，总体原则是对业务进行业务边界的划分，比如做一个企业订购服务网站，你需要把商品类目、商品、订单、订单服务、支付、退款很清晰的划分出来，而业务架构不需要考虑诸如我用什么技术开发、我的并发大怎么办、我选择什么样的硬件等等。
应用架构：应用是介于业务语言与技术语言之间，是对整个系统实现的总体上的架构，他需要指出系统的层次、系统开发的原则、系统各个层次的应用服务，例如，上述系统中可以分为、数据层（资源层）、数据服务层、中间构建服务层、业务逻辑层、表现层，并写明每个层次应用服务。应用架构是要说明产品架构分哪些应用系统，应用系统间是如何集成的，考虑两个事情：第一、考虑的是子系统间的关系。第二、考虑将可复用的组件或模块进行下沉，沉淀到平台层，为业务组件提供统一的支撑。
数据（持久化）架构：对存储数据（资源）的架构方法论，其架构原则同应用架构大同小异，即考虑到各个系统应用场景、不同时间段的应用场景对数据进行诸如数据异构、读写分离、数据库或NOSQL的策略、缓存的使用、分布式数据（数据库）策略等等。 数据架构主要解决三个问题：第一，系统需要什么样的数据；第二，如何存储这些数据；第三，如何进行数据架构设计。
技术架构：应用架构本身只关心需要哪些应用系统，哪些平台来满足业务目标的需求，而不会关心在整个构建过程中你需要使用哪些技术。技术架构是应接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚。技术架构解决的问题包括：如何进行纯技术层面的分层、**开发框架的选择、开发语言的选择、**涉及非功能性需求的技术选择。
总体来看，首先需要熟悉业务，形成业务架构，根据业务架构，做出相应的数据架构和应用架构，最后通过技术架构落地实施。业务架构是战略，应用架构是承上启下，一方面承接业务架构的落地，另一方面影响技术架构的选型。如何针对当前需求，选择合适的架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。
没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往是空中楼阁。
3. 软件架构演变过程
一个成熟的系统架构并不是一开始就设计的非常完美的，世上没有完美的架构，也不是一开始就具备高性能、高可用、安全性等特性，而是随着用户量的不断增加、业务功能的扩展逐步完善演变过来的。在这个过程中，架构也因此也不断的演进、升级、迭代。从单体架构，到分布式架构，到SOA，以及现在火热的微服务架构。如果一个软件开发人员，不了解软件架构的演进，会制约技术的选型和开发人员的生存、晋升空间。这里我列举了目前主要的四种软件架构以及他们的优缺点，希望能够帮助软件开发人员拓展知识面。
3.1单体架构(all in one)
单体架构是最简单的架构风格，也就是把所有的功能模块打包到一起然后再进行部署，采用了单体架构的项目被称之为单体应用。
3.1.1优点
开发简单，测试简单，部署简单
3.1.2缺点
l项目复杂性高，代码严重耦合，代码维护困难单体架构的系统存在代码严重耦合的问题，以一个百万行级别的单体应用为例，整个项目包含的模块非常多、模块的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起。可想而知整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个Bug都会带来隐含的缺陷，修改一处代码，可能会影响一大片的功能无法正常使用。 l欠下一屁股技术债务随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。“ 不坏不修”，这在软件开发中非常常见，在单体应用中这种思想更甚。已使用的系统设计或代码难以被修改，因为应用程序中的其他模块可能会以意料之外的方式使用它。 l部署频率低随着代码的增多，构建和部署的项目时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错率比较高。 l局部功能的修改需要整个系统重新发布， 牵一发而动全身单体架构的系统变更对部署影响大，并且这个问题是所有的单体架构系统都存在的问题。系统作为一个单体部署，每次发布的部署单元就是一个新版本的整个系统，系统内的任何业务逻辑调整都会导致整个系统的重新打包，部署、停机、再重启，进而导致了系统的停机发布时间较长。每次发布上线都是生产系统的重大变更，这种部署模式大大提升了系统风险，降低了系统的可用性。 l可靠性差(连坐)某个应用Bug，例如死循环、内存溢出等，可能会导致整个应用的崩溃 l扩展能力受限单体应用只能作为一个整体进行扩展，无法根据某个业务模块的需要进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更大的内存。如果任何一个模块存在性能问题，那么都需要考虑多部署几个完整的实例的集群，或者再加上负载均衡设备，才能保证整个系统的性能可以支撑用户的使用。 l影响开发效率单体架构的系统影响开发效率。如果一个使用 Java 的简单单体项目代码超过 100 万行，那么在一台笔记本电脑上修改了代码后执行自动编译，可能需要等待十分钟以上，并且内存可能不够编译过程使用，这是非常难以忍受的。或者说因为别的模块出现问题，导致整个系统无法运行，这也是非常难以忍受的。 l系统(应用、项目)启动慢单体架构模式打包后的部署结构可能过于庞大，导致业务系统启动很慢，进而也会影响系统的可用性。这一条也是所有单体架构的系统都有的问题。 l阻碍技术创新，技术栈受限单体应用往往使用统一的技术平台或方案解决所有的问题，团队中的每个成员都必须使用相同的开发语言和框架，要想引入新框架或新技术平台会非常困难。
综上所述，单体架构模式比较适用于规模较小的系统和规模较小的团队，特别是需要快速推出原型实现，以质量换速度的场景。
3.2分布式架构(垂直架构)
分布式和集群：
分布式：多个人完成一件事情 集群：多个人做同样的事情 比如说你开了一家饭店，饭店里有一个厨师，这个厨师又得配菜又得炒菜，这时候万一这个厨师生病了来不了了干不了活，这个时候你的饭店是不是就不可用了，对外提供不了吃饭服务了。这个时候呢你又招了一个厨师，这两个厨师都做的是一模一样的菜，那这两个厨师之间的关系就是集群。为了让厨师能专注的去炒菜，这个时候呢你又招了一个配菜员，配菜员和厨师之间的关系就是分布式。
针对单体架构的不足，为了适应大型项目的开发需求，许多公司将一个单体架构系统业务垂直拆分为若干个子系统，系统之间通过远程接口调用来完成用户的业务处理，每个系统可分布式部署，这种架构称为分布式架构。也就说将一个大系统拆分为多个子系统。
httpclient相互调用。
3.2.1特点
(1) 按业务垂直拆分成一个一个的单体系统，此架构也称为垂直架构。 (2) 系统与系统之间的存在数据冗余，耦合性较大，如上图中三个项目都存在客户信息。 (3) 系统之间的接口多为实现数据同步，如上图中三个项目要同步客户信息。
3.2.2优点：
(1) 通过垂直拆分，每个子系统变成小型系统，功能简单，前期开发成本低，周期短。 (2) 每个子系统可按需灵活的进行伸缩。 (3) 每个子系统可采用不同的技术。
3.2.3缺点：
(1) 子系统之间存在数据冗余、功能冗余，耦合性高。 (2) 按需伸缩粒度不够，对同一个子系统中的不同的业务无法实现，比如订单管理和用户管理。
3.3SOA架构
SOA是一种面向服务的架构，基于分布式架构，它将不同业务功能按服务进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。
3.3.1特点
(1) 基于分布式的架构思想，将重复公用的功能抽取为组件，以服务的方式向各个子系统提供服务。 (2) 各个系统与服务之间采用WebService、HttpClient、RPC等方式进行通信。 (3) ESB企业服务总线作为系统与服务之间通信的桥梁。(ESB可以读取xml中的配置信息，做到多端同步)
3.3.2优点
(1) 将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。 (2) 可以针对不同服务的特点按需伸缩。 (3) 采用ESB减少系统中的接口耦合。
3.3.3缺点
(1) 系统与服务的界限模糊，会导致抽取的服务的粒度过大，系统与服务之间耦合性高。 (2) 虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。
3.4微服务架构
基于SOA架构的思想，为了满足移动互联网对大型项目及多客户端的需求，对服务层进行细粒度的拆分，所拆分的每个服务只完成某个特定的业务功能，比如订单服务只实现订单相关的业务，用户服务实现用户管理相关的业务等等，服务的粒度很小，所以称为微服务架构。
3.4.1特点
(1) 服务层按业务拆分为一个一个的微服务。 (2) 微服务的职责单一。 (3) 微服务之间采用RESTful、RPC等轻量级协议传输。 (4) 有利于采用前后端分离架构。
/p/2accc2840a1b
3.4.2优点
(1) 服务拆分粒度更细，有利于资源重复利用，提高开发效率。 (2) 可以更加精准的制定每个服务的优化方案，按需伸缩。 (3) 适用于互联网时代，产品迭代周期更短。
3.4.3缺点
(1) 开发的复杂性增加，因为一个业务流程需要多个微服务通过网络交互来完成。 (2) 微服务过多，服务治理成本高，不利于系统维护。
(3) 适用于互联网时代，产品迭代周期更短。
3.4.3缺点
(1) 开发的复杂性增加，因为一个业务流程需要多个微服务通过网络交互来完成。 (2) 微服务过多，服务治理成本高，不利于系统维护。
