微服务由SOA演化而来，SOAP切换到REST，更轻量和简单的服务调用协议。
技术角度
从2008年到2018年这十年间，有10个软件技术的“浪潮”。在“微服务”这个词被普遍采用之前，前五种技术浪潮已经存在——
-
第一波包含轻量级容器技术（例如LXC和Docker），这些技术允许在运行时更有效地打包、部署和管理各个服务。
-
第二波包括服务发现技术，它们让服务彼此通信而不明确地提及其网络位置。
-
第三波包括监测技术（例如Graphite和Sensu），这些技术可以运行时监控和分析不同细节层次的微服务资源的行为。
-
第四波包括容器编排技术（例如Mesos和Kubernetes），它们实现了容器分配和管理任务的自动化，抽象出底层的物理或虚拟基础架构。
-
第五波包括延迟和容错通信库（例如Finagle和Hystrix），它们使服务能够更加高效和可靠地进行通信。
其他五个浪潮是为了响应微服务的日益普及而出现的——
-
第六次浪潮包括持续交付技术（例如Ansible和Drone），它们提供通用集成解决方案，以自动化网络规模微服务生产环境中的DevOps实践。
-
第七次浪潮包括混沌工程技术（例如Simian Army和Chaos Toolkit），它可以自动执行关键的全系统可靠性和安全测试技术，例如故障和攻击注入。
-
第八个浪潮包含边车（sidecar）技术（例如Prana和Envoy），它封装了与通信相关的功能，如服务发现和使用协议特定和容错通信库，以便从服务开发人员中抽象出来。
-
第九波包括的无服务器(serverless)计算技术（例如，AWS Lambda和OpenWhisk），该模型实现了FaaS云模型。交付生产更精细的服务功能或功能，而无需创建和管理（例如，应对不一致的流量模式）执行所需的基础设施资源的复杂性。
-
第十波包括服务网格技术（例如，Linkerd和Istio），它们建立在边车技术基础之上，以提供完全集成的服务到服务通信监视和管理环境。
架构角度
微服务架构的四代更迭——
-
第一代：单个服务使用轻量级容器包装，使用容器编排工具运行时部署和管理；但每个服务都要负责自己跟踪其他服务的位置并进行失败处理。
-
第二代：引入服务发现和可重用的容错通信库，但通信库的语言限制了服务的编写语言。
-
第三代：引入标准的服务代理/边车作为一个透明的服务中介。
-
第四代：这个想法是利用最近的FaaS和AWS的Lambda等无服务器-计算技术来进一步简化微服务的开发和交付。有了这种无服务器架构，微服务应用程序将基本上变成短暂的功能的集合，每个功能都可以根据需要快速随意创建、更新、替换和删除。
未来挑战
-
服务的模块化与重构：如何划分模块、分配职责、设计接口
-
服务粒度：不同的项目团队对于微服务的大小规模意见不一致，缺乏统一的标准
-
前端集成：通常是一个巨石的前台使用大量的后台的微服务体系，这导致所有单体体系结构的缺点依旧存在
-
资源监控和管理：信息太多，无法做出及时的管理决策；如何定义一个准确的警告阈值、信息过滤——利用数据挖掘、控制理论和机器学习从历史事件中学习
-
故障、恢复和自我修复
-
组织文化和协调
原文出处——IEEE SOFTWARE | PUBLISHED BY THE IEEE COMPUTER SOCIETY 2018
译文：https://blog.csdn.net/blanchedingding/article/details/81006371