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

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

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

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

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

大家怎么看？