delphi微服务架构

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

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

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

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

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

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

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

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

微服务

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

微服务的优点

隔离性

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

可扩展性

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

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

简化部署

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

易优化

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

动态扩容

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

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

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