基于微服务和SOA架构的技术中台？

SOA架构是一种中心化服务提供为主，基于ESB消息总线统一串联的分层架构，以标准化的接口协议（UUID、WSDL、SOAP、REST）对外提供提供接入方式，服务与服务之间采用模块化、组件化、独立化的方式提供服务，统一向ESB消息总线进行注册，利用ESB消息总线的路由、调度策略实现异步调用。
微服务架构是一种去中心化服务提供为主，将原有的中心服务组件打散形成独立个体，并向统一的注册中心进行注册与路由调用，能够降低系统服务之间耦合，提升其灵活性，采用标准的接口协议：Restful API，微服务架构中各个服务可以独立开发、管理与迭代，当微服务架构中某个服务出现故障，可使其自动降级或其备份服务替代其支撑业务，有效的避免业务的中断带来的损失。
如何从SOA架构向微服务架构转型：
首先对当前系统架构中的服务进行梳理（即横向拆分），把业务量或服务处理handler比较多服务进行拆分，构建独立微服务。
其次就是要对当前系统架构中的服务层级进行梳理（即纵向拆分），按照服务提供上下文对服务进行分层拆解，面向通用能力服务，可以统一抽取公共服务组件；面向数据的构建数据处理微服务组件；面向服务处理，例如：JMS、适配服务、业务流转等等构建其微服务组件。从层次视角来看可分：web层、缓存层、服务层、数据层、数据采集层、数据处理层、基础设施层等等纵向层次划分。
目前市面上比较流行微服务框架：springCloud、Meshos、dubbo、gRPC、 Thrift，各自有其优势，从社区活跃度来看，推荐使用springCloud，功能完善、资料齐全、支持度高、版本持续更新。

SOA与微服务的架构设计都是以技术标准规范实现能力共享的，可以先判断业务是稳态还是敏态，如明确了微服务技术架构对业务发展的支撑必要性，那就有理由坚定以云原生技术建设技术中台，建立新的技术中台标准规范；如遇到与SOA已有能力重叠，建议新的技术中台服务能力与体验要高于原有SOA的，以新的统一云原生技术标准规范推广应用；对SOA上运行的服务可以出于维持业务稳定不动或结合业务迭代契机做技术架构的切换迁移，也就是只减不增。

尽管如您所说，SOA跟微服务存在各种差异，但是从本质上来讲，集成的核心是协议，协议的标准是统一，从某种角度上讲，微服务是实现SOA的一种最佳实践方案。根据康威准则，微服务的体系架构一定跟组织的逻辑结构相一致，或者与业务关系相一致。对于一个公司的系统架构来讲，开放、统一协议、标准、易扩展，我认为是最重要的。只有统一的协议接口，才使得未来扩展更加容易，才能让已有的服务成为资产，相当于搭好了基座，上面都是标准的垒砖。只要是接收了统一协议，标准，具备开放的理念，相信您心中定有答案