【微服务】微服务与SOA
作为一名软件开发者，技术爱好者，微服务、docker、k8s这样的术语我们已经很熟悉，但是你是否知道这些为什么会崛起？今天小编将带您了解微服务的由来，以及微服务我们该知道的事。
凡事存在即合理，我们要了解新事物，首先要了解历史，历史会告诉我们新事物的产生，由来，所以我们需要用历史的眼光看待微服务的出现。
SOA简史
2000年初，SOA崛起，这是一种非常流行的软件架构设计范式。简言之，SOA是一种软件架构模式，用于构建大型的企业应用程序，这些应用程序通常要求集成多种服务，而每种服务使用不同的平台和编程语言来构建，并通过通用的通信机制交互（该通信机制是ESB）。
SOA是大型软件产品（如企业应用程序）的首选，但其本质是单体，也就是说，单个应用程序包含了用户界面或表示层、业务、DB，这些都集成到一个平台。
关于单体服务
以网店为例，电商网站，一些服务负责创建账号、显示目录、建立购物车、生成账单、订单、支付等，在单体应用程序中，这些服务都在同一个应用程序运行：
随着服务量增加，应用程序规模不断增长，技术栈难以更新，每项变更都要开发人员重建整个应用，浪费资源；随着客户群增加，我们将有更多的请求需要，这将需要更多的资源，因此建立可扩展的产品至关重要。对于单体应用程序，我们只能在一个方向伸缩，即垂直伸缩，而不是水平伸缩。这意味着我们要添加更多硬件资源在单台计算机上扩展应用程序，但横向扩展仍然是一项挑战。
我们对单体架构总结为以下几点：
复杂性逐渐变高
有的项目有几十万行代码，各模块模糊，逻辑混乱，代码越多越复杂。
技术债务逐渐上升
公司人员流动，有的员工离职前疏于代码质量的自我管束，留下很多坑，代码量庞大，留下的坑很难发觉。
部署速度逐渐变慢
模块多，代码量庞大，部署项目花费时间越来越多。
阻碍技术创新
比如之前的项目使用struts2，各模块联系紧密，逻辑不够清楚，如果再想spring mvc重构，很困难，付出的成本将很大，所以公司不得不硬着头皮继续使用老的struts架构，阻碍了技术创新。
无法按需伸缩
比如电影模块CPU密集，订单模块IO密集，所有模块在一个架构下，在扩展其中一个性能的时候不得不考虑其他模块，无法按需伸缩。
救星“微服务”来了
一种可以克服单体架构缺陷的替代模式。它的目的就是有效拆分应用，实现敏捷开发和部署。
对比微服务与SOA
到这里，我们对微服务的由来大概有一些明白了，下篇博客小编将讨论微服务的相关知识，什么情况适合用微服务，怎么权衡微服务的利与弊，期待您的来访。
相关博客：
【微服务】走进微服务
【微服务】Zuul的必要性
【微服务】服务通信
【微服务】Eureka与Zk
【微服务】噩梦不再是噩梦
【微服务】Ribbon和Feign负载均衡
【微服务】服务熔断与降级（一）
【微服务】服务熔断与降级（二）
【微服务】分布式配置中心
感谢您的阅读！
痛定思痛。
分手后的思念是犯贱
小灰灰
还没有评论，来说两句吧...