看了网络上的一些资料，也看了一些书本上的资料。
总体上感觉就是混乱。结合自身的经验和体会，列出几个关心的要点和个人心得。
实际的东西，读者还是去看看有关更加专业的书籍。
一、定义
”名不正，则言不顺。言不顺，则事不成“。
简而言之，”软件架构“可以理解为解决软件设计的通用方法，是关于不同功能/结构之间的组合方法。
或者，可以简单类比为一个集体内部，应该如何协作以便更好地解决问题；一个军队内部，不同的作战单位应该如何互相协作。
从软件工程的角度出发，”软件架构“算是比较上层的，宽泛的技术概念，但要理解为工程管理概念未尝不可。
所以，世间万物就是这样：具有多个角度，又互相联系。
二、混乱的说法
因为历史的缘故，关于”软件架构“，在百度等地方可以搜索出非常多的内容，着实混乱得很。
例如：
五种常见软件架构 - 时间朋友 - 博客园 (cnblogs.com)
10种常见的软件架构模式 - 林本托 - 博客园 (cnblogs.com)
程序员必知的7种软件架构模式 - 知乎 (zhihu.com)
以前常常谈论"C/S","B/S"，"SOA","SAAS",还有其它一些名词。
再换个角度，还有其它名词，例如”电商架构“、”企业架构“、”大型互联网架构“，等等。。。
所以整体还是有点混乱，因为角度不同，所以同个东西可能会有不同叫法。
标准不是非常统一，也不算非常严谨。
一般大学中，相对缺乏讨论这个问题（非常可惜）的学科。
须知，由于人类认知的特点，和局限性，如果不先来个相对统一的大概念，那么必然会导致有关人员的思维混沌。
三、常用架构
这里摘取几个个人认为比较有用的架构，主要来自五种常见软件架构 - 时间朋友 - 博客园 (cnblogs.com)
1.分层/层叠-上层依赖下层（一般而言）。特点：简单明了。现在人人都会
2.事件驱动-组件之间靠事件来驱动。没事就没有关系。要算”架构“比较勉强
3.微核/插件架构-非常典型的是eclipse的设计。好处是足够扩展和灵活，缺点是有点吃性能，如果没有好好管理插件。
4.微服务-某种程度上足够灵活，但消耗偏大。常用于处理不是那么关键的任务，仅仅是因为微服务更好伸缩。 不是特别大的事务，建议不要上这个，否则你会后悔的，唯一的受益者就是那些所谓的”技术爱好者“。
5.云架构？ 核心就是花钱办大事，把功能拆分成一只只蚂蚁。现在和微服务有点关系。
6.管道架构？ 例如过滤器，netty的消息处理
四、使用架构的目的
实现两个目标：
1.工程管理-例如微服务可以较大提升运维的压力
2.市场需求-在实现管理目标前提下，可以考虑由此产生的市场目标。 事实上不少框架是因为有市场需求才产生的。
软件框架，是典型地通过技术来实现管理目标的一个例子。软件架构对于工程管理的作用，基本等同于组织结构对于组织的作用。
一个合适的架构，能够满足特定目标，例如：
- 可靠性 -- 甲方必须的。甲乙方节省维护支出
- 可扩展性 -- 一般是乙方节省支出
- 可维护 -- 一般是乙方节省支出
但最终目的是：让甲方满意，让乙方赚钱（更快的实施速度、更地的运营成本）。
五、小结
一个项目需要采用什么架构，需要考虑的因素比较多：
- 商业目标
- 项目周期
- 甲方投入
- 项目组的能力
- 是否需要吹牛
- ....
从乙方的角度出发，如果不是做很大很复杂的项目，轻易不要采用微服务、云架构。
从管理者角度出发，且不可技术为向导，为技术而技术，永远要牢记--技术服务于商业，亏本的买卖不能做！
如果有人总是撺掇你在并发只有几千的项目中使用微服务，那么要好好考虑那人的目的了。
如果是出于增加团队的技能点，为将来的项目做准备，是可以适当考虑在1，2个宽松的项目中练手，但不要夸大化范围。