微服务架构——看上去很美

[sing1ee]

一直被架构这个词吓的不轻，创业过程中也是如履薄冰。
之所以觉得微服务的架构很美，也是因为我们现在确实经历着一些问题，恰好微服务的目标就是解决这些：
1. 几乎所有的逻辑，都在一个项目中，一个小的按需改动，都需要严格评估影响有哪些，甚至还有遗漏。
2. 部署比较重。可能本次更改的，只是一个小的功能，但其他功能，在部署过程中会受到影响。项目越大，这个时间也越长。
3. 我们现在用SpringBoot开发，就是Java，想换成Python成本好高，即使是新功能。
4. 如果渐渐出现问题，真个项目部署多台服务器，有浪费，并不是每个部分，访问的压力都大。
5. 随着项目的变大，内存溢出的可能性也越来越大。
6. 随着项目的变大，开发团队的配合，能力要求都比较高，少有人能够完全清晰一个大项目里的各个细节。如果这个人离开了，灾难来了。

综上，似乎很需要一个微服务的架构，我看到的微服务架构的介绍，就是解决上面的问题的。很好。但一下的点，需要更成熟：
1. 微服务会也来越多，如何组织管理，我所希望的服务管理：自动注册、负载均衡、监控，支持跨语言的服务之间的异步、同步通信，支持暴露restful api。
2. 部署起来要方便，每一个是很快部署，但是几百个微服务呢？docker目前似乎不太稳定，我们的实践中，会不明宕掉。kubernetes研究中，还没用。
3. 数据库的实践，如何做会更好，减少重复，降低依赖，减少变化的影响面，都要考虑，似乎矛盾。

想看看大家对微服务的看法，有不少创业团队宣称采用了微服务的架构，是如何的实践的呢？服务的管理用的是什么呢？我看有用dubbo的。

微服务就是SOA，不用强调restful这些，也不用强调更轻，没有出了SOA的大范畴的。

大家怎么看？

[incompatible]

系统的演进路线基本上就是 大杂烩->组件化->服务化
你的问题中除了4与5之外的几个问题，我认为组件化就可以解决了
至于4与5，水平scale out即可解决。

另外，服务化需要着重考虑的问题之一就是事务。目前的服务化方案基本没有可以支持分布式事务的；而且说到底分布式事务在实际开发中并不是一个良好的实践。
你的业务是否易于拆分成不支持事务的一个个服务？

[easynoder]

Dubbo + ZooKeeper 组合挺不错的，Dubbo在国内挺流行的，据我所知，当当、京东、亚信等等挺多公司都在使用这个RPC框架，另外，为了将Dubbo服务能够已resf形式发布，当当网内部对此作了扩展，即Dubbox，

[JamesRuan]

你需要Erlang，开发快，到处都是微服务，部署也是so easy。

既然选择Python，应该是考虑到快速开发的能力，同时带来的项目管理问题会比Java更加严重。