标签：服务 1.1 Spring 系统 源码 应用 架构 单一 衍进
1.1 架构的衍进
随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。
互联网产品常常面临庞大的用户量，日均数十亿 PV 的高并发， PB 级别的数据存储等问题的挑战，同时要求保证系统的高可用和弹性伸缩，并且能够根据需要进行快速迭代扩展，这些都对于系统架构提出了很高的要求。
互联网架构从简到繁的演进至今，大体上可分为这么几个阶段：单一应用架构 -> 垂直应用架构 -> 微服务架构。
1.1.1 单一应用架构
当网站流量很小时，只需要一个应用，将所有的功能都部署在一起，用来减少部署节点和成本。这时，用于简化增删改查工作量的数据访问框架(ORM)是关键。我们更加关注的是简化开发工作。如图1-1：
特点：
- 所有的功能集中在一个工程中。
- 应用与数据库分开部署。
- 通过部署应用集群和数据库集群来提高系统的性能。
优点：
- 项目架构简单，前期开发成本低，周期短，小型项目的首选。
缺点：
- 全部功能集中在一个工程中，代码耦合，对于大型项目不易扩展及维护。
- 提高系统性能只能通过扩展集群，成本高。
- 单点容错率低。
1.1.2 垂直应用架构
当访问量逐渐增大，功能逐渐复杂起来，单一应用架构就显得有些捉襟见肘，由于所有的功能都写在同一个工程中，整个工程会越来越庞大越来越臃肿，每次发布上线拆分代码版本和合并代码版本都将成为噩梦，同时，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。如图1-2：
特点：
- 将项目以单一应用架构的方式，将一个大应用拆分成为几个互不干扰的应用。
- 应用于应用之间互不相干，功能和数据都会存在冗余。
优点：
- 通过垂直拆分，防止单体项目无限扩大。
- 系统间相互独立。
缺点：
- 项目拆分之后，项目与项目之间存在数据冗余，耦合性较大。
- 提高系统性能只能通过扩展集群，成本高，并且存在瓶颈。
1.1.3 微服务架构
当垂直应用越来越多，应用与应用之间的交互不可避免，这时需要将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务，使前端应用能更快速的响应多变的市场需求。如图1-3：
特点：
- 系统服务层完全独立，并且抽取成一个一个的独立服务。
- 微服务遵循单一原则。
- 使用服务中心进行服务注册与发现。
- 每个服务有自己的独立数据源。
- 微服务之间采用 RESTful 等轻量协议传输。
优点：
- 通过分解巨大单体式应用为多个服务方法解决了复杂性问题。
- 可以更加精准的制定每个服务的优化方案，提高系统可维护性。
- 微服务架构模式是每个微服务独立的部署，可以使每个服务独立扩展。
- 微服务架构采用去中心化思想，服务之间采用 RESTful 等轻量协议通信。
缺点：
- 微服务过多，服务治理成本高，对系统运维团队挑战大。
- 分布式系统开发的技术成本高（容错、分布式事务等），对团队挑战大。
极客挖掘机
博客专家
发布了150 篇原创文章 · 获赞 1339 · 访问量 13万+
私信
关注
标签：服务,1.1,Spring,系统,源码,应用,架构,单一,衍进 来源： https://blog.csdn.net/meteor_93/article/details/104019931
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。