在本篇文章，我们的第一节会先解释什么是单体系统、微服务架构与DevOps文化的概念，接下来的第二节一起讨论软件架构及其重要性，最后我会向大家介绍软件架构体系结构的模板，它可以用于现代软件应用的开发，如单体与微服务的应用。

我们总结了架构参考体系。请各位看下图：

部署单体服务器、微服务与DevOps

如果架构设计正确，现代软件系统可以完全支撑从数十个用户到数千万用户，而无需更改任何源代码。

举例来说，从2009年以来，因为有效利用了AWS公有云（Long和Bastani），Netfix的流量从2013年到2017年增加了100倍，但是得益于云计算的弹性，实现了前所未有的高效可扩展。

此外，持续集成与持续交付的方法地，让软件质量和自动化部署得到了极大的改进。

在2011年，AWS每11.6秒就会对生产环境做一次升级，但是不会影响最终用户。

如果系统仍然采用单体方法地，软件应用程序作为单一单元部署，云计算就无法施展太多。尽管开发人员很容易理解单体方法，而且这种软件架构已经沿用了十多年，但是它业已成为新技术趋势的瓶颈。

在单体方法时，软件系统大多是在同一技术栈中开发，使用集中式的数据库存储，同时使用复杂的、水平划分，基于集群的复制，作为可伸缩性策略。

目前微服务架构已成为基于云的应用程序设计开发的事实标准。这些因素和趋势包括云计算，遍布全球的工作人员，上线时间与需求，各种技术栈的选择，智能手机、物联网的负载增加。

微服务架构基于将软件开发为服务模块化。这些服务的特征：小巧，独立，可以自我部署，只围绕业务功能设计，只管理自己的数据，通过轻量级协议（有可能是HTTP）与其它的服务进行通信。

在微服务中，每个服务都由专门的团队来设计、开发与运维。该团队完全决定这个服务的设计和技术，这种团队的结构与管理方法被称为DevOps。

什么是软件架构，为什么要使用架构

软件开发的过程主要是给最终用户和企业相关利益方期待的产品功能，在软件工程学科中，这类功能称为功能需求。

大多数情况，技术团队可以在不遵循软件最佳实践和良好架构的情况下实现功能需求。例如，可以在一个文件中实现全功能的信息通信功能（包括安全性、用户验证、集成以及审计），这个文件可能有数百行代码。

但是，在最后一个属性，很多的应用就无法支撑长时间的运营。从内部测试、用户验收、测试与上线，问题和bug将在很多阶段开始显现。

软件产品的主要关注点是可靠性（始终实现所需的功能）与可维护性（维护和修改此应用的能力）。另外，其它的问题还包括可扩展性与安全性，这导致了不同类型的需求：非功能性需求，也就是质量属性。

质量属性主要分为：功能性、可靠性、效率、可维护性和可移植属性。可以在https://en.wikipedia.org/wiki/List_of_system_quality_attributes 查看更完整的质量属性列表。

作为一个软工出身者，一直秉持功能可靠、有效率、易读易维护、方便移植。功能是用户需求，这是基本要求，规范是团队需求，质量是用户体验需求，易读易维护可扩展方便移植是追求。

美国软件工程协会（SEI）在属性驱动设计方法（ADD 2.0)中提出更广泛的术语，被称为架构重要性的需求。

ASR包括：

1、设计目的

2、品质属性

3、主要功能

4、架构问题

5、相关约束

例如，设计目的可以是提案、概念验证或最终产品，这些因素会影响架构设计和开发过程。

软件架构的价值与重要性，在于将内部和外部利益关联在一起，将软件质量达到人们可接受的水平。

例如，对于有活力的市场，例如初创公司的生态系统，产品上线时间非常重要，因此可维护性应具有最高优先级，比如对于支付网关，安全与可审计性是非常重要的。

面向服务的体系结构（SOA）与微服务

过去十年中，大多数企业采用的是面向服务体系结构（SOA）。SOA的主要目标是通过提供单一企业应用的标准接口作为服务来实现更高级别的可重用性和模块化，能够使用业务流程和集成平台来编排业务流程来协调这些服务。

SOA的概念，在可重用、灵活性的角度上来看，很像微服务，但是在组织的巨额投资上来讲，没有更好的预期结果。

工具的复杂性，过度设计的平台，通信开销以及使企业部门自动化以及开发完整流程的需求等方面，SOA在许多情况下并不是最正确的选择。

SOA和微服务之间的区别总结如下：

1、SOA服务通过重量折智能管道（ESB）进行通信，微服务通过转储管道与智能端点进行通信（Fowler，2014）。

2、SOA旨在将企业大型复杂的单体应用程序集成到企业的流程中，而微服务旨在将小型微服务集成到单个项目中（Richardson，2018）。

3、SOA是基于企业的，微服务是基于项目的（Wolff，2016）。

4、在SOA中，业务流程被创建并由平台管理。在微服务中，业务流程被编写为应用程序级别，如果流程发生变化，可以由另一个服务替换（Wolff，2016）。

现代参考架构

本节是我对现代软件架构的看法列表。它基于其部署策略（基于单体与微服务），分布性质（后端分布式与非分布式）以及与后端（服务器端与客户端前端）与前端耦合进行分类。

1.带服务器端前端的非分布式单体架构

在此体系结构中，如图1所示，应用程序是使用3层体系结构开发的，该体系结构在单个进程中运行。在这种方法中，可以使用JavaEE（JSP或JSF），Spring MVC（FreeMarker，Thymeleaf或JSP）开发前端，使用服务器端脚本语言（如PHP或Python）进行动态网页呈现。

图1：单体架构版本1（未使用服务器端前端架构进行分发）。

这种架构的优点是开发简单、方便。但是，可扩展性，可维护性和安全性是缺点。此外，对现代前端技术（如智能手机应用程序，小程序）的支持也可能具有挑战性。

2.具有客户端前端的非分布式单体架构

除了前端和后端分成两个子系统外，此架构与上一个架构类似。在这种方法中，前端将在客户端完全运行，而后端将作为服务器端进程运行。该架构的组件图如下图所示。

图2：单体版本2（未使用客户端前端进行分发）。

在这种情况下，前端使用的潜在技术可能是

传统的Web前端技术，包括HTML，Bootstrap，CSS和JavaScript。

基于JavaScript的前端框架，如Angular、vue或React。

原生客户端应用程序，如Android，iOS或桌面级应用程序。

混合应用程序，如Electron，Cordova，PhoneGap或Xamarin。

这种方法可以实现前端和后端之间的技术分离，可以轻松支持新的前端，而无需对后端代码进行任何修改。

3.具有前端的分布式单体版本

在此版本中，应用程序分为4层（单独进程），其中每个层通过网络与其相邻的层进行通信，如图3所示。

图3：单体版本3（与客户端前端一起分发）。

在这种架构中，即使在开发、部署和操作中增加了额外复杂度，它也可实现更高级别的模块化和每个层的可重用性，其中任何层都可以轻松地用另一层替换。此外，它也被认为比前两种方法中提供的单层架构更安全，它有更好的可伸缩性，尤其是在实现异步通信的情况下（通过使用事件驱动技术或传统的消息传递，如JMS消息传递服务）。

4.非云原生微服务

此设计是使用微服务架构风格。特别是应用程序被模块化为可独立部署的自包含服务。在微服务架构中，每个服务的业务功能独立，并管理自己的独立数据库。该设计如下图所示。

图4：微服务版本1（非云原生）。

微服务可以在不影响其它服务的情况下逐步开发和部署服务和功能。此外，它通过微服务级别（不是应用程序级别）的水平可伸缩性实现了更高效的可伸缩性。

微服务的主要挑战包括应用程序微服务化时早期架构时决策难度，它们的规范以及通信协议。Martin Fowler的建议是延后开展单体化并重构微服务。他是基于有一个遵循最佳实践，设计模式和代码重构过程的团队。笔者并不完全同意这一点，因为将应用程序从单片机重构为微服务的代价会非常昂贵，特别是它的设计没有考虑未来的重构。

微服务实施的潜在技术包括：

Spring Boot
Drop Wizard.
Java Micro配置
Node.JS
Python

从理论上讲，任何技术谈论HTTP都可以用来开发微服务。

5.云原生微服务

本节中讨论的体系结构基于云原生微服务架构。在这种架构中，基于微服务的应用程序将充分利用基于12因子概念云计算的全部优势。图5显示了该架构的原理。

图5：微服务版本2（基于云原生的基础）。

对于中小规模的基于云的应用程序，此设计可能已足够。但是对于更复杂和更大规模的应用程序，应考虑更多的基础架构微服务，例如Spring Cloud项目提供的开箱即用的组件。

此外，其他一些开源项目可能有助于探索，例如用于实时基于Web的应用程序监控的Spring Boot Admin和为基于云的应用程序的JHipster项目。

小结

在本文中，我们一起了解了对现实应用程序的软件架构的看法。我们分别介绍了软件架构，微服务架构，DevOps和SOA的定义和重要性。

与任何其它新趋势和技术一样，微服务和云原生应用程序的概念仍处于早期阶段，并且仍在不断发展，因此关于它们的争论和争论将会持续一段时间。

参考资料：

Martin Fowler和James Lewis，2014年，“微服务”。

https://www.martinfowler.com/articles/microservices.html

Martin Fowler，2015年，“Monolith First”。

https://martinfowler.com/bliki/MonolithFirst.html

Eberhard Wolff，2016，“微服务：灵活的软件架构”。

https://www.amazon.com/Microservices-Flexible-Architecture-Eberhard-Wolff/dp/0134602412

Chris Richardson，2018年，“微服务模式”。

Chris Richarson，2018，“http://microservices.io/”。

Josh Long和Kenny Bastani，2017年，“云原生Java：使用Spring Boot，Spring Cloud和Cloud Foundry设计弹性系统”

Matt McLarty，2016年，“从SOA学习：微服务时代的5个课程”。

Spring Cloud-Native，2018“https://pivotal.io/cloud-native”。

Rick Kazman和Humberto Cervantes，2016，“设计软件架构：实用方法”

https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=454919

Ian Sommerville，2016年，“软件工程（第10版）”。

https://www.amazon.com/Software-Engineering-10th-Ian-Sommerville/dp/0133943038

本文收藏来自互联网，用于学习研究，著作权归原作者所有，如有侵权请联系删除

markdown @tsingchan

部分引用格式为收藏注解，比如本句就是注解，非作者原文。

单体架构与微服务

目录