zoukankan      html  css  js  c++  java
  • delphi 微服务

    delphi微服务架构

    微服务架构

    微服务架构区别于传统的单体软件架构,是一种为了适应当前互联网后台服务的三高需求:高并发、高性能、高可用,而产生的软件架构。

    与微服务相对的另一个概念是传统的单体式应用程序(Monolithic application),单体式应用内部包含了所有需要的服务。而且和个服务功能模块有很强的耦合性,也就是相比依赖彼此,很难拆分和扩容。

    单体式应用程序的优点:开发简洁,容易部署,容易测试。

    单体应用程序的缺点:项目刚开始需求少,业务逻辑简单,写代码一直爽,一直爽。噩梦从业务迭代更新,系统日益庞大开始,前期的爽没有了,取而代之的是软件维护和迭代更新的无尽痛苦。

    由于单体式应用程序就像一个大型容器一样,里面放置了许多服务,且他们是密不可分的,这导致应用程序在扩展时必须以应用程序为单位。当里面有个业务模块负载过高时,并不能够单独扩展该服务,必须扩展整个应用程序,这可能导致额外的资源浪费。

    相比这下,微服务架构能够解决这个问题。

    合久必分,鉴于单体应用程序有上述的缺点,单个应用程序被划分成各种小的、互相连接的微服务,一个微服务完成一个比较单一的功能,相互之间保持独立和解耦合,这就是微服务架构。

    在IT世界没有什么技术是永不过时的,微服务架构的演进就是一个例子,从单体程序到微服务架构,我不知道下一个技术迭代点是什么时候,但我知道微服务架构肯定还会更新,IT人应该建立终身学习习惯。当然更重要的是拥有对技术的热情,热于拥抱变化、接受新技术,当我看到新技术我是兴奋的,内心OS是厉害了,还能这么玩!而不仅仅是面向工资编程,生活会有趣很多。

    微服务

    微服务(Microservices)就是一些协同工作小而自治的服务。

    微服务的优点

    隔离性

    一个服务不可用不会导致另一个服务也瘫痪,因为各个服务是相互独立和自治的系统。这在单体应用程序中是做不到的,单体应用程序中某个模块瘫痪,必将导致整个系统不可用,当然,单体程序也可以在不同机器上部署同样的程序来实现备份,不过,同在存在上面说的资源浪费问题。

    可扩展性

    庞大的单体服务如果出现性能瓶颈只能对整体进行扩展,可能真正影响性能的只是其中一个很小的模块,我们也不得不付出升级整个应用的代价。这在微服务架构中得到了改善,你可

    以只对那些影响性能的服务做扩展升级,这样对症下药的效果是很好的。

    简化部署

    如果你的服务是一个越大的单体服务,有几百万行代码,即使修改了同行代码也要重新编译整个应用,这显然是非常繁琐的,而且软件变更事业的不确定性非常高,软件部署的影响也非常大。在微服务架构中,各个服务的部署是独立的,如果真出了问题也只影响单个服务,可以快速回滚版本解决。

    易优化

    微服务架构中单个服务的代码量不会很大,这样当你需要重构或者优化这部分服务的时候,就会容易很多,毕竟,代码量越少意味着代码改动带来的影响越可控。

    动态扩容

    一般来说,一个微服务都会部署多个实例,这样一来能够分担压力提高性能,二来即使一个实例挂了其他实例还能响应。

    服务发现服务。各个微服务在启动时自动将自己注册到代理服务上。代理服务会定期检查微服务的健康状态,去掉不健康的微服务。这样扩容时只需要部署新的微服务,微服务下线时直接关停服务即可,代理服务发现会自动检查服务实例的增减。

    客户端负载均衡。由于微服务已经同步服务地址列表在代理服务了,所以客户端请求服务时,代理服务可以自己决定负载策略。

     

  • 相关阅读:
    .net core系列之《.net平台历程介绍以及.net framework和.net core对比》
    C++ 拷贝构造函数
    C++ const引用
    C++ 引用和指针
    C++ 将派生类赋值给基类(向上转型)
    C++ 虚继承
    C++ 基类和派生类的构造函数以及析构函数
    C++ 类继承时的作用域嵌套和对象内存模型
    C++ private + protected + public
    C++ const成员变量、成员函数和对象
  • 原文地址:https://www.cnblogs.com/hnxxcxg/p/14284995.html
Copyright © 2011-2022 走看看