单体架构和微服务架构
Posted Eurya
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了单体架构和微服务架构相关的知识，希望对你有一定的参考价值。
一，单体架构
优点
1，部署简单：由于是完整的结构体，可以直接部署在一个服务器上即可
2，技术单一：项目不需要复杂的技术栈，一套熟悉的技术栈就可以开发
3，用人成本低：单个程序员就可以完成业务接口到数据库的整个流程
缺点
1，系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长;
2，系统错误隔离性差、可用性差，任何一个模块的错误均可能造成整个系统的宕机;
3，可伸缩性差:系统的扩容只能只对这个应用进行扩容，无法结合业务模块的特点进行伸缩。
4，线上问题修复周期长:任何一个线上问题修复需要对整个应用系统进行全面升级。
5，跨语言程度差
6，不利于安全管理，所有开发人员都拥有全量代码
二，微服务
1.微服务架构的优势
1.易于开发和维护
一个微服务只关注一个特定的业务功能，所以它的业务清晰、代码量较少。开发和维护单个
微服务相对比较简单，整个应用是由若干个微服务构建而成，所以整个应用也会维持在可控
状态;
2.单个微服务启动较快
单个微服务代码量较少，所以启动会比较快;
3.局部修改容易部署
单体应用只要有修改，就要重新部署整个应用，微服务解决了这样的问题。一般来说，对某
个微服务进行修改,只需要重新部署这个服务即可;
4.技术栈不受限
在微服务中，我们可以结合项目业务及团队的特点，合理地选择技术栈
5.按需伸缩
2.微服务架构的缺点(挑战)
1、服务太多，导致服务间的依赖错综复杂，运维难度大
2、微服务放大了分布式架构的系列问题
·分布式事务(seata) .
·分布式锁怎么处理(redisson),
·服务注册与发现(nacos).
·依赖服务不稳定(sentinel）导致服务雪崩怎么办?
3、运维复杂度陡增，部署数量多、监控进程多导致整体运维复杂度提升。
单体架构和微服务架构:现实应用中的软件架构
如果没有一个好的架构，软件系统的开发可能会使公司付出很高的代价。举个例子，如果一个在线电子商务公司开发平台采用耦合程度高的模块化方法，用户界面和业务逻辑功能的源文件是混在一起的，如果想要支持新的智能手机本地应用或支持更大规模的用户交易，他们可能会需要大量的投资(时间和资源)。这种系统设计风格会影响软件的可维护性，质量，并会增加业务投放市场的时间。
本文旨在为读者提供一个可作为设计现代软件项目基础的参考系统体系架构列表。
所提出的体系架构是基于以下三个因素设计的：分布式的或非分布式的、前端(服务器端或客户端)，最后是单体的或微服务。
在本文中，第一节首先解释单体系统架构、微服务体系架构和DevOps文化的概念。第二节讨论软件体系架构的一般意义及其重要性。第四部分介绍了参考体系架构的列表，这些体系架构以用于现代软件应用程序的开发：基于单体和基于微服务的应用程序。
一、整体部署、微服务、DevOps
如果设计得当，现代软件系统可能会从数千万用户扩展到数千万用户，而无需改变源代码，例如，由于使用了亚马逊Web服务公共云(Long and Bastani, 2017)，从2009年起，NetFlix的需求在2013年增长了100倍。多亏了云计算的弹性，使空前有效的可扩展性成为可能。此外，持续集成和持续交付方法使软件质量和部署自动化得到了极大的改善。例如，2011年，亚马逊在不影响终端用户(Richardson, 2018)的情况下，每11.6秒就部署了一次生产变更。
然而，如果系统仍然采用单体架构的方式(Wolff, 2016)来设计，云计算就无法发挥多大的作用，在这种方式下，软件应用程序被部署为一个单元。尽管单体架构的方法很容易被开发人员理解并且已经被采用了几十年，但是随着新技术的发展趋势，它已经成为一个瓶颈。
在单体架构中，软件系统很可能在相同的技术堆栈中开发，使用一个集中式的数据库存储库，并使用重量级的、水平的、基于集群的复制作为可伸缩性策略。
由于许多因素，微服务体系结构已经成为设计和开发基于云的互联网应用程序的实际标准。这些因素和趋势包括云计算、全球劳动力、需要更快的上市时间、各种技术选择、智能手机和物联网带来的负载增加。
微服务体系结构基于将软件项目开发为模块化服务，这些服务是:小型的、自包含的、可自部署的、围绕业务功能设计的、管理自己的数据以及通过轻量级协议(最有可能是HTTP)与其他服务通信的。
在微服务中，每个服务都是由一个专门的团队设计、开发和操作的，这个团队对服务的设计和技术几乎有一个完整的决定。这种团队结构和管理的方法称为DevOps。
二、什么是软件架构，为什么需要软件架构?
软件开发过程的主要目的是交付最终用户和外部涉众所期望的主要功能。在软件工程学科中，这类功能被称为功能需求(Sommerville, 2016)。
大多数时候，不遵循最佳实践或没有良好的体系结构就可以实现功能需求。例如，想要实现一个完整的“银行汇款”功能(包括安全性、验证、集成和审核)，可以在一个文件中实现全部功能(可能需要有几十行代码)。
然而，在最后一个示例中，应用程序将不会持续很长时间。问题将在许多阶段中开始显现，从内部测试开始，用户验收测试，到实时测试。主要关注的是可靠性(按照预期实现所需的功能)和可维护性(维护和应用此功能的更改的能力)。此外，其他潜在的问题包括可扩展性和安全性等。这导致了一种不同类型的需求：非功能性需求(即质量属性)。
质量属性主要分为功能属性、可靠性属性、可用性属性、效率属性、可维护性属性和可移植性属性。质量属性的完整列表可以在这里找到（https://en.wikipedia.org/wiki/List_of_system_quality_attributes）。
软件工程学院(SEI)在属性驱动设计方法(ADD 2.0)中提出的一个更广泛的术语，叫做体系结构显著性需求(ASR)。
ASR包括：
设计的目的
质量属性
主要功能
架构
约束
例如，设计目的可能是一个提议，一个概念验证，或者一个最终的产品，它将会显著地影响建筑设计的范围和过程。
软件架构的重要性在于实现内部和外部涉众所接受的级别的质量属性。例如，在像初创公司的生态系统这样充满活力的市场中，时间到市场是非常重要的，所以可维护性应该是高优先级的。而对于在线支付网关来说，安全性和可审核性是非常重要的。
三、面向服务的体系结构(SOA)和微服务
面向服务体系结构(Service Oriented Architecture, SOA)是过去十年中大多数企业采用的一种体系结构风格。它的主要目标是通过提供单个企业应用程序的标准接口作为服务来实现更高层次的可重用性和模块化，并能够通过使用编排和集成平台来构建业务流程。
尽管SOA概念看起来像从可重用性和灵活性角度来看的微服务，但是巨大投资并没有获得预期的结果。
“我们已经看到了许多面向服务的拙劣实现——从在esb中隐藏复杂性的倾向，到花费数百万美元却没有价值的失败的多年计划，再到积极抑制变化的集中治理模型，有时很难忽略这些问题。”(Fowler,2014)
工具的复杂性、过度设计的平台、通信开销以及自动化所有企业部门以开发完整流程的需要，这些都是限制因素，在许多情况下，SOA不是正确的选择。
SOA和微服务之间的主要区别总结如下：
SOA服务通过重量级智能管道(ESB)进行通信，微服务通过转储管道与智能端点进行通信(Fowler,2014)。
SOA旨在将企业大型复杂的单体应用程序集成到企业范围的流程中，而微服务则旨在将小型微服务集成到单个项目中(Richardson, 2018)。
SOA是基于企业范围的，微服务是基于项目的(Wolff, 2016)。
在SOA中，业务流程被创建为编排并由平台管理，在微服务中，业务流程被编写为应用程序级别上的另一个微服务，如果流程发生更改，则可以由另一个服务替代(Wolff, 2016)。
四、现代的参考体系结构
这一部分包含了我对现代软件架构的看法。它基于其部署策略(单体与基于微服务的)、分布特性(分布式与非分布式后端)以及前端与后端(服务器端与客户端前端)的耦合进行分类。
1、非分布式单体与服务器端前端
在这个体系结构中，如图1所示，应用程序是使用在单个进程中运行的三层体系结构开发的。
在这种方法中，前端可以使用Java EE(JSP或JSF)、Spring MVC (FreeMarker、Thymeleaf或JSP)以及使用服务器端脚本语言(如PHP或Python)进行动态HTML呈现。
这种方法的主要优点是开发简单和方便。然而，可扩展性、可维护性和安全性是主要的关注点。此外，对现代前端技术(如智能手机应用)的支持也可能会出现问题。
2、客户端前端的非分布式单体
这个设计与前面的设计类似，只是前端和后端被分成两个子系统。在这种方法中，前端将在客户端完全运行，而后端将作为服务器端进程运行。
这个体系结构的组件图如下图所示：
在这种情况下，用于前端的潜在技术可能是：
1）、传统的web前端技术，包括HTML、Bootstrap、CSS和JavaScript。
2）、基于Javascript的客户端框架，如Angular或React框架。
3）、本机客户端应用程序，如Android、iOS或桌面应用程序。
4）、混合应用程序，如Cordova, PhoneGap，或Xamarin。
这种方法允许在前端和后端之间进行技术分离，在这种情况下，无需对后端进行任何修改就可以轻松支持新的前端。
3、分布式单体和客户端前端
在这个版本中，应用程序被划分为4层(独立的进程)，其中每个层通过网络与它旁边的层进行通信，如下图所示：
在这个体系结构中，即使在开发、部署和操作中增加了额外的复杂性，它也支持每一层的模块化程度和可重用性，其中任何一层都可以很容易地被另一层所取代。此外，它被认为比前两种方法所提供的一层架构更安全。此外，它还允许更有效的可伸缩性，特别是在实现异步通信时(可能通过使用事件驱动的响应技术或传统的消息传递，如Java消息传递服务)。
4、非云的原生微服务（Non-Cloud Native Microservices）
该设计利用了微服务架构风格。特别是，应用程序被模块化为独立部署的自包含服务。在微服务体系结构中，每个服务都应该围绕业务功能设计，并管理自己的数据库。
这个设计如下图所示：
微服务支持软件开发的演化方法，其中服务和特性可以逐步开发和部署，而不会影响其他服务。此外，通过在微服务级别(而不是应用程序级别)上的轻量级水平可扩展性，它可以实现更高效的可扩展性。
微服务的主要挑战包括应用程序的微服务的早期架构决策的困难、它们的规范和它们的通信契约。事实上，Martin Fowler的建议是先开始构建单体的应用，稍后再重构到微服务架构。我认为Martin的建议是基于一个遵循最佳实践、设计模式和代码重构过程的团队。然而，我并不完全同意这一点，因为重构一个从整体到微服务的应用程序可能非常昂贵，特别是如果它最开始不是为将来的重构设计的。
微服务实现的潜在技术包括：
Spring Boot.
Drop Wizard.
Java Micro profile.
NodeJS.
Python.
理论上，任何与HTTP有关的技术都可以用来开发微服务。
5. 原生云微服务（Cloud-Native Microservices）
本节讨论的体系结构基于云本地微服务体系结构。在这种方法中，基于微服务的应用程序将利用云计算的全部好处。
下图显示了这个体系结构的基本内容：
这种设计对于中小型基于云的应用程序来说可能已经足够了。但是，对于更复杂和更大规模的应用程序，应该考虑更多的基础设施微服务，比如Spring Cloud项目提供的组件。
此外，其他的开放源码项目可能会很有用，比如用于实时基于web的应用程序监控的Spring Boot Admin和为基于云的应用程序提供很好的生成器的JHipster项目。
结论
在本文中，我介绍了我对现实应用程序的现代软件体系结构的看法。介绍了软件体系结构、微服务体系结构、DevOps和SOA的定义和重要性。
与其他任何新趋势和技术一样，我认为微服务和云本地应用程序的概念仍处于早期阶段，而且还在不断发展，因此关于它们的争论将会持续一段时间。
请注意
下面是一个高质量的图，其中包含了所有所提供的参考体系结构。
引用
Martin Fowler and James Lewis, 2014, "Microservices".
Martin Fowler, 2015, "Monolith First".
Eberhard Wolff, 2016, "Microservices: Flexible Software Architecture".
Chris Richardson, 2018, "Microservices Patterns" .
Chris Richarson, 2018, "http://microservices.io/".
Josh Long and Kenny Bastani, 2017, "Cloud Native Java: Designing Resilient Systems with Spring Boot, Spring Cloud, and Cloud Foundry"
Matt McLarty, 2016, "Learn from SOA: 5 lessons for the microservices era".
Spring Cloud-Native, 2018 "https://pivotal.io/cloud-native".
Rick Kazman and Humberto Cervantes, 2016, "Designing Software Architectures: A Practical Approach"
Ian Sommerville, 2016, "Software Engineering (10th Edition)".
以上是关于单体架构和微服务架构的主要内容，如果未能解决你的问题，请参考以下文章