大家觉得现在的微服务架构最需要什么？
传统的SOA的中心是ESB，统一做消息的转发和转换，当然ESB本身的中心化结构会带来单点问题和性能问题。
微服务在各个节点上可以用Docker来启动服务本身，然后外部引入ZooKeeper或者etcd这样的服务发现机制。当然，目前而言Docker的持久化层还需要加强。
那么，对于一个组织或者说开发者来说，创建微服务架构的技术痛点在哪里呢？是否对应用开发者自身要求（抽象能力、组织能力）比较高？
目前而言，在软件通信的各个设计中，我最喜欢的是UNIX的管道，简单、高效、兼容一切，把所有数据都认为是一个文件流而组合了所有的程序。但在现代系统中，已经很难看到这么简洁明快的设计了。所以我想是否有一种方式，能让分布式系统中的程序通信达到unix管道这样的高度？
微服务在各个节点上可以用Docker来启动服务本身，然后外部引入ZooKeeper或者etcd这样的服务发现机制。当然，目前而言Docker的持久化层还需要加强。
那么，对于一个组织或者说开发者来说，创建微服务架构的技术痛点在哪里呢？是否对应用开发者自身要求（抽象能力、组织能力）比较高？
目前而言，在软件通信的各个设计中，我最喜欢的是UNIX的管道，简单、高效、兼容一切，把所有数据都认为是一个文件流而组合了所有的程序。但在现代系统中，已经很难看到这么简洁明快的设计了。所以我想是否有一种方式，能让分布式系统中的程序通信达到unix管道这样的高度？
4同行回答
浏览1700
原来UNIX下的简单是因为原来的应用简单，在互联网模式下应用的复杂度和规模已经远超当时，因此如果不做改变是不能适应现在的需求的。
关于SOA，我觉得在电商及互联网领域（也就是涉及海量数据和高并发处理）必须放弃ESB——每次中转造成的延时在至少电商看来是不可接受的；
至于是微服务，这要看企业的应用能够拆分的粒度，而且拆分越多则投入一般也越大；能拆分到什么程度会考验企业及架构师的能力收起
关于SOA，我觉得在电商及互联网领域（也就是涉及海量数据和高并发处理）必须放弃ESB——每次中转造成的延时在至少电商看来是不可接受的；
至于是微服务，这要看企业的应用能够拆分的粒度，而且拆分越多则投入一般也越大；能拆分到什么程度会考验企业及架构师的能力收起
浏览1380