浅谈微服务架构的优劣势及影响

 

微服务架构是一种从SOA架构演化过来的新型架构。微服务架构具有许多优点。例如在微服务架构中每个服务都有其自己单独的数据库，能够单独部署，并在其自己的进程中运行而互不影响等。微服务架构的这些优点使得它更适合互联网公司敏捷开发、快速迭代版本。

网站架构的演变

传统架构，也就是单体式应用的所有业务模块都会在一个项目中开发，并最终打包成一个war部署在tomcat上。传统架构是一种很自然的架构，非常适合个人和小团队开发。但传统架构也存在着许多问题。首先是耦合度太高，它的处理请求的所有逻辑都在一个进程中运行，一个模块出错会影响到其他模块。其次，每一次对应用程序进行修改都需要重新编译和部署整个程序。并且随着项目功能的逐渐增大，应用程序会变得越来越庞大，以至于企业敏捷开发和部署都举步维艰。同时，传统架构也因代码冲突问题，不适合中大规模团队开发。

为了改进传统架构的缺点，分布式架构被提了出来。分布式架构将传统的项目以项目模块拆分成多个子项目。每个项目中都有自己独立的数据库和redis等。相比于传统架构，分布式架构项目粒度更加细腻，耦合度更低，更加适合互联网公司开发。分布式架构的缺点在于它需要开发大量的远程通讯接口，增加了应用设计和研发的复杂度。此外，随着节点数的增加和分布部署，对运维管理、异常处置也提出了更高的要求。

SOA架构也是基于分布式架构演变过来的。SOA架构意为面向服务。它将共同的业务代码抽取出来，提供给其他接口调用。服务与服务之间采用RPC远程调用技术。它的特点是底层基于SOAP或者ESB实现，底层使用HTTP或者HTTPS+XML数据交换格式实现。SOA架构也具有许多不足的地方。首先是它依赖于复杂的中心化服务发现机制。其次SOA架构采用SOAP协议，而SOAP中XML传输协议比较占用宽带，报文有大量冗余数据，不适合高并发开发。最后，SOA架构服务管理混乱，缺乏服务管理，带来了管理上的不便。

微服务架构的出现

微服务架构也从SOA架构演变过来。在微服务架构种，每个服务只负责非常明确、独立、简单的任务处理，并将处理结构以API的形式返回给外部。从实践的角度来看。微服务时对整个软件平台或项目的细粒化拆分，拆分后的所有微服务独立运行，互不干扰。每个微服务都运行在独立的容器中。

因为微服务架构比SOA架构在粒度上更加精细，所以更能让专业的人更加专注做其专业的事情。同时服务与服务之间采用HTTP协议+json数据传输格式通信。

微服务架构的优势在于，首先通过分解巨大的单体式应用为多个服务的方法解决了单体式应用过于庞大的问题。在功能不变的情况下，单体式应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。

其次，微服务架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。

再次，微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。

最后，微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。

微服务架构的不足

微服务架构也像任何其它科技一样有不足之处。微服务架构应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更加严重的是他们必须写额外代码来处理消息传递中速度过慢或者不可用等局部失效问题。相对于单体式应用中通过语言层级的方法或者进程调用，微服务架构下这种技术显得更复杂一些。

第二个关于微服务的缺点来自于分区的数据库架构。商业交易中经常需要同时给多个业务主体更新消息。这种交易对于单体式应用来说很容易，因为只有一个数据库。但在微服务架构应用中，则需要同时更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择。最终，开发者不得不使用一个最终一致性的方法，从而再一次对开发者提出了更高的要求和挑战。

第三个缺点，测试一个基于微服务架构的应用是一项很复杂的任务。对一个单体式应用来说，要测试它的各种接口功能是很容易的事情。而微服务架构的应用来说，一个服务可能与许许多多的其它服务相关。因微服务架构而带来的复杂性有时候会远超想象，并给测试工作带来非常繁重的工作量。

第四个缺点是微服务架构模式下应用的任何修改可能存在波及多个服务的风险。比如，假设你在完成一个案例，需要修改服务A、B、C，而A依赖B，B依赖C。在单体式应用中，你只需要改变相关模块，整合变化，部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务造成的影响。比如，你需要更新服务C，则需要考虑更新对所有依赖于C的服务的影响。

最后，部署一个微服务架构应用也很复杂。一个微服务架构应用常常由大量服务构成。例如Hailo有160个不同服务构成，NetFlix有大约600个不同服务构成。每个服务都有多个实例。这么多实例单纯靠人工的力量来监测是非常费时费力的一件事。因此成功部署一个微服务架构应用需要开发者有足够自动化的控制部署方法。

 

微服务架构的影响

目前微服务架构尽在一些中大型公司里得到了事件，还没有完全被中小型企业接受。由于微服务架构的优势，给相关行业带来的将不只是软件开发管理上的影响。

微服务架构的灵活性可以使项目的开发国产更易于管理，从而大幅提升项目开发团队的开发效率。微服务独立性、分外分割的设计四象可以使开发人员更加关心组件内部构造，从而提高代码质量。同时，服务的复用使得开发人员从以往的代码、对象、模块复用种解脱出来。服务复用真正实现了“一次部署，无限使用”。这将使企业在构建后续功能时，大幅降低人力和时间成本。同时，微服务架构的出现使得初创项目的软件开发可以遵循由中心到外围，由重要到次要的次序，降低因需求临时变动带来的对项目整体性的冲击，加速项目的形成。另外，随着微服务开发者的增多，越来越多开发者愿意将自己开发的微服务开放给全网用户进行使用。

 

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

#1楼 2019-04-16 19:33 | 金石软件   在二维线性可分情况下，支持向量机和线性回归有什么区别     答： 在二维线性可分的情况下，最明显的差别是支持向量机与（狭义上的）线性回归的损失函数不同。支持向量机是要最大化支持向量与分界面之间的距离。而线性回归是要让总体误差最小。   其次，支持向量机只考虑支持向量，线性回归考虑所有的数据。   最后用线性回归做分类，可能会因初始状态、步长等因素出现多个结果（梯度下降法）。支持向量机能确定唯一分割面。   显然支持向量机具有更好的泛化能力。   支持向量机与逻辑回归（广义线性回归）上的区别在于：首先也是损失函数不同。逻辑回归是交叉熵损失函数。   支持向量机只考虑支持向量，逻辑回归考虑所有的数据。这一点也是一样的。   逻辑回归产生的是概率，支持向量机不是。   逻辑回归是参数模型，支持向量机不是。   支持向量机自带结构风险最小化（损失函数中带正则项），逻辑回归则是经验风险最小化。   普遍来说当数据较少时使用支持向量机比较合适，数据较多时使用逻辑回归比较合适。

标签：SOA,服务,结课,报告,部署,软件体系结构,应用,架构,向量
来源： https://www.cnblogs.com/asagiyukina/p/10745663.html