如果看待将Web应用的DAO层和API层都包装成独立的服务这种做法？

回复内容：

1. dao web api

如前面所说，这个完全没有意义，属于意淫出来的架构，反而把架构搞复杂。要清楚当前我们谈的最多的组件化和服务化，绝对不是说逻辑层和数据层之间要服务化拆开，而更多强调的是组件之间要服务化拆开。

对于dao web api唯一的意义在于屏蔽底层的多种数据库类型，但是这个工作当前已经由类似Hibernate框架来解决掉了。其次如上图中的dao api本身不会有任何逻辑处理，仅仅是接受和传输数据，如果是业务和dao api都要分服务器部署，显然本身意义不大。

2.api服务代理层

注意这一层相对来说必要性很大，主要表现在两个方面。

其一是有这层后已经可以用来实现一个轻量的服务总线，即对所有组件提供出来的http api接口服务进行统一管理。当前多数open api开放平台都存在这一层。这一层的目的不是简单的实现服务代理，你可以看到对于服务本身的负载均衡，流量控制，log日志记录和审计，访问安全控制等都可以在proxy服务代理层统一实现，而不是每一个http api都去实现一遍。

其二即前面提高过的出于安全的考虑，有了api代理这层后，由于api代理本身没有任何业务规则和逻辑，仅仅是请求的代理和转发，因此实现api代理的服务器可以部署在整个基础设施架构中的DMZ区，通过DMZ区+防火墙来实现内部和外部访问之间的强安全特点。 提升GDP。 在不同的需求场景下，两种方案都有其合理性。

如果是简单的网站，中小型的，展示性的，搞这么复杂纯粹给自己找事，要么就是冲一波 KPI。

如果是交易型的、大型的、多端的网站，第二种合适，毕竟可靠、解耦、可扩展性都比较好。 增加一个服务代理层，可能是为了负载均衡。
新加入的Web dao层，我们不是没有这样的设计。但这样的设计要单独鉴权，而且在调用的时候，要在发起请求的地方自己实现一个宽粒度的应用程序级事务。这在设计上多了一个中间层，使得数据门面得以解耦，性能却会急剧下降。因为这涉及到事务实现和隔离的问题，对客户端代码要求极高，是不必要的负担。 DAO web api是什么鬼？
事务如何保证？ ←_←API服务代理层完全没问题……
DAO WEB API 是什么鬼…… dao web api是谁想出来的？这层的后面要不要再加dao logic层和dao dao层？ 这种dao的web api好像martin大叔提过，但我觉得答主公司应该碰不到那种情况吧 为了应用之间的内部调用？那开放部分接口就行了 1、数据库放自己公司里，不想托管（例如客户、交易、金融数据之类的）。
2、应用服务器做互联网服务，给互联网客户使用。
这种场景应该很多吧，然而直接把数据库服务器直接放给互联网或者VPN都不安全，因为只需要一个跳板就能拿到整个数据库的权限。那么，我们一起来做个DAO Web API吧，应用服务器要什么数据，我就开放什么数据。防火墙也保持原样，继续只开80和443就好了。