对于一个新事物的诞生，本能地套用已有的知识。特别是一个并不简单的东西，这算是一种高效的入门方法。微服务架构其实相当复杂，我是分成好几个阶段理解。

1、第一阶段，微服务架构就是去掉了ESB的SOA架构，只不过是通信的方式和结构变了。对于初级的使用者而言，这样理解没有太大问题。

2、第二阶段，没有了ESB，原本很多由ESB组件做的事儿，转到服务的提供者和调用者这里了。他们需要考虑服务的拆分粒。大体仍然算是SOA架构。

3、第三阶段，随着服务的数量大幅增加，服务的管理越来越困难，此时DevOps出现了。这个阶段的微服务架构，已经是跟SOA架构完全不同的东西了。

之前给一家大国企分享过一些经验。他们想从传统架构，转向微服务架构。

1、建设好基础设施，RPC、服务治理、日志、监控、持续集成、持续部署、运维自动化是基本的，其它包括服务编排、分布式追踪等。

2、要逐步演进和迭代，不要过于激进，更不要拆分过细，拆分的粒度，要与团队的架构相互匹配。（康威定律）

3、微服务与数据库方面，是个很大的难点，可以深入了解下领域驱动设计，做好领域建模，特别是数据库要随着服务一起拆分。

说完上面这些，他们的研发负责人说，我说的跟他们的架构师说的不一样，他们的架构师说，微服务就是各种拆分，不顾一切地拆分。

之前一家公司搞了一次完整的微服务改造，享受到了一些好处，但是文中说到的问题，大部分都碰上了。
先说下好处，原来的单体应用都服务化了，扩容简单很多。功能隔离后之前一个bug导致系统挂掉的现象没了。问题责任定位划分的更清楚，比如之前大量慢sql无人管，现在通过监控快速找到开发责任人。
再说下坏处，1.服务太多了，人不够啊。之前的架构师按照小的原则，把数据层，服务层，应用层严格拆分。一个人手上超过10几个服务...
2.服务化不彻底，太多事手工干。服务监控只能监控一半指标，各种远程调用异常没人解决。运维只有打包发布做了自动化。可以想象下开发人员基本下改bug和发布的死循环中。服务网关没有，服务调用就是一张密密麻麻的网
3.培训不到位，直接上阵，开发人员对微服务理解不到位，服务质量可想而知
4.没有专职测试，自动化测试靠开发写脚本，谁有空啊，单元测试能写一个就算相当有觉悟了
总结下来，做服务化改造首先问自己这些问题，业务真的需要微服务来解决吗？真的所有模块的问题都要微服务来解决吗？技术人员的配置和水平达到要求了吗？

我们是一家社交公司，后端加厚的演变符合dubbo官网的那张图，在Mvc架构坚持了一年后，业务越来越大，工程越来越臃肿。后面我们一致同意进行服务话，开始用了dubbo。后面由于决策层的原因没有上，后面来了个架构师，又重启了服务拆分，到现在已经用于生产。我们使用的是Spring cloud，现在拆分暴露了很多问题:
1、个别服务没有熔断出来，出现过雪崩效应
2、服务拆分过细，服务调用链过长
3、开发人员能力不一样，代码水平不一样
4、没有监控措施
5、每个服务部署多台，日志查询就会死人的感觉
6、开发过程中经常出现访问不到该访问的接口，这是因为开发人员经常启动本地服务，就会导致30%的概率访问不到
7、使用了不合理的持久层框架，使用了JPA访问
大概就有上面的问题，总之微服务不是银弹，用得不好会发现无穷无尽的坑。当然，出现问题解决问题就是了。唯一的就像CEO说的: 你们他妈的是完全在拿用户当小白鼠使用

说到微服务，切分的粒度和基础设施都致关重要。

经历的项目有创业初期的单体服务，也有不太完善的服务切分的系统，也有微服务基础设施相对完善的公司。

单体服务致命就致命在随着项目的发展，项目会越来越臃肿，越不利于扩展开发。

微服务过程怕就怕基础不完善，人员配备不够盲目切分，导致工程师开发和维护的战线拉长，特别疲惫和泄气，容易产生一种抱怨的大气氛，从而导致微服务失败，重新合并一部分服务。

微服务做的好的，也有所经历，公司的基础设施完全云化和统一管理，申请几台机器，一套缓存集群，一套mq，sql/nosql…特别容易，工程师愿意建独立的工程，因为很容易构建和部署。这种感觉有点像svn和git，git建分支特别轻量，大家都愿意用分支管理自己的代码，迭代开发，应急处理都能自由切换，得心应手。

现在遇到一个问题，就是微服务内部系统大多使用rpc，但对接外部系统，或者跨外网传输到客户端就需要http-rest类的协议。也就是我们常说的网关，如果是纯http就很容易做到通用的转发机制，但是http转rpc就不知道有什么方式可以做到通用转发了，内部每增加一个rpc，网关就需要增加一个对应的服务处理逻辑。不知道，这个问题，有没有好的解决办法？

我们的业务也算是微服务吧，    接手项目时，已经有好多服务，主要采用的语言有java，php，nodejs，存在以下问题：
1、没有一个统一的网关服务，前端请求后端服务都需要后端的服务A来充当安全校验，权限校验等，A服务充当了多重职责，变的职责不明确了，后来抽出网关系统，负责平台统一的流量入口。在构建微服务网关系统是至关重要的。
2、监控系统不完善，调用链跟踪，异常报警都不完善，对微服务是巨坑，查找问题如同一场噩梦，调用链很长，一旦发生异常不知道到底哪里出现问题，得一个一个去找。后来慢慢完善，变得好了很多，问题很快定位。
3、加入网关后，没有一个统一的服务发现注册中心，网关的路由依靠人工手动配置，变的很麻烦，也很容易出错。后来引入consul，得到改善。

个人觉得SOA只是提出了面向服务的编程，到但没有对服务粒度的定义，以及服务的治理问题做深入的分析。
提出微服务主要是为了解决面向服务架构后如何能够在实际工程中带来真正的红利。
微服务对SOA的技术关键点给出了指导意见。


微服务对分布式服务的诱惑力的确很大，但做但微服务都不会免费的，需要很多的基础设施来做铺垫和基石，才有可能搞定。

除了基础设施还有很多设计思想需要学习，我觉得DDD就是微服务的绝配。