微服务架构的特点

微服务架构风格大家基本上耳熟能详，有着显著的特点，包括并不限于：

应用组成：应用中包含多个小型组件或者服务。
部署特点：每个应用均可独立部署。
松散耦合：服务之间松散耦合，以API、RPC或者中间件方式进行通信。
开放技术栈：每个服务可以使用不同的技术栈实现，包括编程语言、库和开发工具。

微服务架构的演进历史回顾

和其他许多架构方法一样，微服务并非一夜之间出现并大火，而是有具体背景催生，并不断演化而来。

单体架构

一把梭，所有代码和业务实现均集中在单个工程内。适用场景：

业务简单，单人能够理解全局信息
流量少，单实例即可满足
参与开发的人员少，基本不存在编辑冲突
原型验证，不需要考虑直接实用化

在很多简单场景下如工业自动化软件、嵌入式软件，单体架构的应用应用仍然十分广泛。

显著问题：

随着功能迭代，项目会变得臃肿，业务耦合严重。新增业务变得困难，核⼼业务与边缘业务互相影响

集群化和垂直化架构

主要思路是进行子系统分治，组合成一个更复杂、并发更高的系统。

通过子系统拆分、垂直化部署和负载均衡，方便横向扩容解决并发问题。
可以针对不同子系统模块进行优化。
子系统之间相互独立，互不影响。

问题在于：

服务间的相互调用依赖硬编码或者静态配置。
服务之间调用协议和接口不统一

SOA架构

SOA（Service Oriented Architecure,面向服务的架构）经考古是二十世纪九十年代后期出现的架构（那时候我刚出生？），SOA 定义了通过服务接口复用软件组件的方法，此类接口会使用通用的通信标准，这些标准能够快速合并到新应用程序中，而不必每次都执行深度集成。SOA架构有几个显著特点：

基于SOA架构思想，将重复的功能抽取为组件，以服务的形式在向各系统提供服务。
使用企业服务总线（ESB）集成不同的组件和服务。
系统与服务之间使用rpc、web service等方式进行通信。

什么是 ESB（企业服务总线）？ ESB（企业服务总线）是一种模式，可让集中式软件组件执行后端系统集成（以及数据模型转换、深度连接、路由和请求），并将这些集成和转换作为服务接口提供，以供新应用程序复用。通常使用专用的集成运行时和工具集来实施 ESB 模式，以确保最佳的生产力。

优点：

集中式 ESB 有可能标准化和大幅简化整个企业中服务的通信及集成。
服务层的存在提高了可重用性、可维护性，提高了开发效率
ESB使模块间的通信减少了耦合
ESB兼容不同协议使得集成更加灵活

缺点：

ESB容易成为SOA部署、变更活动中的瓶颈，更改或增强某个集成通常会干扰到其他集成
ESB对种类繁多协议的集成，使得ESB在后期变得臃肿难以维护。

对于互联网行业，随着分布式应用逐渐普及，SOA似乎逐渐成为了过去式，但在特定的领域如汽车制造，为了实现软件定义汽车，汽车软件正在从传统的”面向信号”开发范式，转型升级为SOA架构。汽车行业很可能复制PC和智能手机的“底层硬件、中间层操作系统、上层应用程序”的软件分工模式，工业级的SOA框架使得上层APP开发者无须关注底层硬件架构和模块交互细节，而专注于应用开发。