这是我参与「第五届青训营」伴学笔记创作活动的第7天。
前言
作为一个学过spring那一套的Java Boy，我对架构还是有一定认识的，也知道架构的演变过程。因此，今天的课程是当作复习课来上的，心情是放松的，没有昨天的课程那么懵逼了。
知识点内容
1.架构定义
关于架构的定义，我们先来看下正经解释：架构，又称软件架构，是有关软件整体结构与组件的抽象描述，用于指导软件系统各个方面的设计。 它的定义相对来说还是比较通俗的，但是我们也可以类比一下，我们开发一个软件就好像盖房子一样，而架构就是房子的地基，如果地基没建好，这个房子就是危房了；同理，一个软件的架构没有设计好，那就是“在屎山上继续堆屎上”。所以，一个良好的架构基础，它可以为软件的未来发展提供了更多的可能，有利于自身的口碑，也可为用户赋能，实现自身价值。
2.架构的演变
软件架构的发展经历了以下的演变过程，这里我画图举例一个电商系统（Ps:只是简单对比看下，真实的电商系统当然比我画的复杂）来对照看：
2-1.单机架构
所有的东西都在一个进程里，部署在一个机器上。
优点：简单
缺点：
- 运维需要停服，用户体验较差
- 承载能力有限。
2-2.单体架构
在单机架构的基础上，将进程部署到多个机器上。
优点：
- 具备水平扩容能力
- 运维不需要停服
缺点：
- 后端进程职责太多，越来越臃肿
- 爆炸半径较大，进程中一个很小的模块出现问题，都可能导致整个进程崩溃
2-3.垂直应用架构
在单机架构基础上，将进程按照某种依据切分开。比如，图中的电商系统原先采用单机架构部署，那就是一个进程部署在多个机器上；如果用垂直应用架构，可以将电商系统的后端拆分为两个进程，然后再按照单体模式的思路，部署在多个机器上。
优点：
- 一定程度上减少了后端进程职责
- 一定程度上缩小爆炸半径
缺点：
- 没有根本解决单体架构的问题
2-4.SOA (面向服务架构)
SOA 架构中，服务为一等公民，将进程按照不同的功能单元进行抽象，拆分为【服务】。有了服务之后，SOA 还为服务之间的通信定义了标准，保证各个服务之间通讯体验的一致性。
优点：
- 各服务的职责更清晰
- 运维粒度减小到服务，爆炸半径可控
缺点：
- ESB (企业服务总线) 往往需要一整套解决方案
2-5.微服务
在 SOA 架构中，ESB 起到了至关重要的作用。但从架构拓扑来看，它更像是一个集中式的模块。有一个 SOA 分布式演进的分支，最终的形态便是微服务。
优点：
- 兼具 SOA 解决的问题
- 服务间的通信更敏捷、灵活
缺点：
- 运维成本
从架构的演变过程，我们可以看到在这个过程里提升了软件迭代的效率，归根结底，还是为了业务而产生的服务，因此，在日常的开发中，我们所做的一切都是为了业务。另外，可以看到架构演变的思路是朝着模块化、分布式方向演变的，解耦再解耦。
3.企业级后端架构剖析
这一部分在青训营的资料中很详细，不过多赘述了，目前这一阶段的内容也就了解了解，毕竟不会有公司招一个实习生进去就搞架构，但是这方面的知识看看扩充下自己的眼界总是好的，毕竟云原生现在也很“火”。包括资料里的有关企业级后端架构目前面临的挑战也很值得一看，会将这部分内容放在文末的参考文献。
小结
通过今天的学习，我再次接触到了架构方面的知识，在当初学习spring cloud的时候就已经了解到了一些关于架构的知识，而今天这堂课给我最大的收获就是知道了目前在实际企业开发中架构的使用以及面临的挑战，在未来的工作之余的时间，自己也会考虑看看这方面的内容。
