认识达内从这里开始

无论是微服务架构还是面向服务架构程序都是目前大多数软件开发程序员都在使用的一种编程开发技术，下面我们就通过案例分析来了解一下，微服务架构还是面向服务架构

1、面向服务架构喜欢重用，微服务喜欢重写

面向服务架构的主要目的是为了企业各个系统更加容易地融合在一起。说到面向服务架构不得不说ESB(EnterpriseServiceBus)。ESB是什么?可以把ESB想象成一个连接所有企业级服务的脚手架。通过servicebroker，它可以把不同数据格式或模型转成canonical格式，把XML的输入转成CSV传给legacy服务，把面向服务架构P1.1服务转成面向服务架构P1.2等等。它还可以把一个服务路由到另一个服务上，也可以集中化管理业务逻辑，规则和验证等等。它还有一个重要功能是消息队列和事件驱动的消息传递，比如把JMS服务转化成面向服务架构P协议。各服务间可能有复杂的依赖关系。

微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。我们向微服务迁移的时候通常从耦合度低的模块或对扩展性要求高的模块开始，把它们一个一个剥离出来用敏捷地重写，可以尝试新的技术和语言和框架，然后单独布署。它通常不依赖其他服务。微服务中常用的APIGateway的模式主要目的也不是重用代码，而是减少客户端和服务间的往来。APIgateway模式不等同与Facade模式，我们可以使用如future之类的调用，甚至返回不完整数据。

2、面向服务架构喜欢水平服务，微服务喜欢垂直服务

面向服务架构设计喜欢给服务分层(如ServiceLayers模式)。我们常常见到一个Entity服务层的设计，美其名曰DataAccessLayer。这种设计要求所有的服务都通过这个Entity服务层来获取数据。这种设计非常不灵活，比如每次数据层的改动都可能影响到所有业务层的服务。而每个微服务通常有它自己独立的datastore。我们在拆分数据库时可以适当的做些去范式化(denormalization)，让它不需要依赖其他服务的数据。

微服务通常是直接面对用户的，每个微服务通常直接为用户提供某个功能。类似的功能可能针对手机有一个服务，针对机顶盒是另外一个服务。在面向服务架构设计模式中这种情况通常会用到Multi-ChannelEndpoint的模式返回一个大而全的结果兼顾到所有的客户端的需求。

3、面向服务架构喜欢自上而下，微服务喜欢自下而上

面向服务架构架构在设计开始时会先定义好服务合同(servicecontract)。它喜欢集中管理所有的服务，包括集中管理业务逻辑，数据，流程，schema，等等。它使用EnterpriseInventory和ServiceComposition等方法来集中管理服务。面向服务架构架构通常会预先把每个模块服务接口都定义好。模块系统间的通讯必须遵守这些接口，各服务是针对他们的调用者。

面向服务架构架构适用于TOGAF之类的架构方法论。

微服务则敏捷得多。只要用户用得到，就先把这个服务挖出来。然后针对性的，快速确认业务需求，快速开发迭代。另外，SpringCloud微服务系列面试题和答案全部整理好了，微信搜索Java技术栈，在后台发送：面试，可以在线阅读。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。