1、SOA喜欢重用，微服务喜欢重写
SOA的主要目的是为了企业各个系统更加容易地融合在一起。 说到SOA不得不说ESB(EnterpriseService Bus)。 ESB是什么? 可以把ESB想象成一个连接所有企业级服务的脚手架。
通过service broker，它可以把不同数据格式或模型转成canonical格式，把XML的输入转成CSV传给legacy服务，把SOAP 1.1服务转成 SOAP 1.2等等。 它还可以把一个服务
路由到另一个服务上，也可以集中化管理业务逻辑，规则和验证等等。 它还有一个重要功能是消息队列和事件驱动的消息传递，比如把JMS服务转化成SOAP协议。 各服务间可能有
复杂的依赖关系。
微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始，
把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然后单独布署。 它通常不依赖其他服务。微服务中常用的API Gateway的模式主要目的也不是重用代码，
而是减少客户端和服务间的往来。API gateway模式不等同与Facade模式，我们可以使用如future之类的调用，甚至返回不完整数据。
2、SOA喜欢水平服务，微服务喜欢垂直服务
SOA设计喜欢给服务分层(如Service Layers模式)。 我们常常见到一个Entity服务层的设计，美其名曰Data Access Layer。 这种设计要求所有的服务都通过这个Entity服务层
来获取数据。 这种设计非常不灵活，比如每次数据层的改动都可能影响到所有业务层的服务。 而每个微服务通常有它自己独立的data store。 我们在拆分数据库时可以适当的做些
去范式化(denormalization)，让它不需要依赖其他服务的数据。
微服务通常是直接面对用户的，每个微服务通常直接为用户提供某个功能。 类似的功能可能针对手机有一个服务，针对机顶盒是另外一个服务。 在SOA设计模式中这种情况通常会用到
Multi-ChannelEndpoint的模式返回一个大而全的结果兼顾到所有的客户端的需求。
3、SOA喜欢自上而下，微服务喜欢自下而上
SOA架构在设计开始时会先定义好服务合同(service contract)。 它喜欢集中管理所有的服务，包括集中管理业务逻辑，数据，流程，schema，等等。 它使用Enterprise
Inventory和Service Composition等方法来集中管理服务。 SOA架构通常会预先把每个模块服务接口都定义好。 模块系统间的通讯必须遵守这些接口，各服务是针对他们的调用者。
SOA架构适用于TOGAF之类的架构方法论。
微服务则敏捷得多。只要用户用得到，就先把这个服务挖出来。然后针对性的，快速确认业务需求，快速开发迭代。
网友评论