大家好，我是张飞洪，面对观望或正在转型或已然入坑的微粉们，这里收集了网上那些运用微服务踩到的坑和想入门微服务面临的困惑的留言，每个留言的解答都可能牵扯到一系列知识点，这里抛砖引玉，对错自行辨别，希望你能绕过去，帮助团队和开发更好的实践微服务！
留言1
服务化最难的是在数据库层，因为数据库中很多数据都是相互关联的，比如用户用户跟订单，订单和商品等等这些数据之间都是有关联的，服务拆分之后会面临以下问题:
1.当需要读取关联数据时，如果采用表连接的方式查询数据会出现跨数据库查询的可能。
2.如果是通过RPC的方式多次调用(比如要查订单，就需要查询商品及订单详细信息)，也会出现多次调用导致的频繁多次的数据库连接，而如果使用缓存，也会面临数据库与缓存之间的数据同步问题，特别是数据库与缓存服务器都存在集群的情况下，会更难处理，这也是在做微服务之前必须要考虑的问题。
解读：服务化拆分最好不要涉及跨数据库表交互！
坑2：
1. 项目内结构依旧混乱，A 模块和 B 模块都依赖于 C 模块，我们的做法是，A 模块里写一次 C 模块，B 模块同样写一遍 C 模块。其中有两个原因，无法实现分布式事务，只好放到同一个系统内，整个流程可以同属于一个事务；另一个原因是模块的边界划分是很模糊的。
2. 项目之间的依赖关系就跟意大利面条一样，而且之间的接口，并没有想着去向下兼容，甚至发生过接口定义变更了，导致线上依赖的服务都无法正常提供服务。现在每次发布也是战战兢兢。
目前面临最大的问题便是分布式事务的问题，导致 DAO 层的代码，重复散落在各个模块之中，真是令人头大。
建言：第一点，可以抽离出哪些是公共的模块，并且请求量和重要性值得这么做。第二点，接口定义最好不要随便变更，这是原则，可以添加参数，新增返回字段，也可以新增接口，但最好不要改参数名或者已有字段。
坑3：
我们目前的系统就是从单体到服务化再到微服务化的，第一次转变是为了减少大计算量的模块带来的阻塞，提高负载，第二次转变是因为系统已经比较庞大，需要切分的更细，并且便于开发维护。目前用了spring cloud和docker，遇到的最大的问题是数据库伴随服务的切分以及一致性带来的复杂度提升
建言：微服务有利有弊，总体来看，利大于弊！
坑4：
我所在的公司正在进行微服务化的系统改造，原有的系统是一个巨大的单体架构业务系统。在改造过程中我的困惑是微服务的拆分粒度，拆的大了感觉效果不好，拆的细了业务调用链太长，造成系统响应变慢，问题定位不容易等问题。
建言：看着办！
坑5：
现在好多公司强推微服务，不考虑实际情况，单体应用并不是就一定很脆弱，系统不稳定，服务拆分了也不一定稳定，开发效率不高，没准是流程问题，系统本身设计问题耦合严重，单体应用设计不好，玩不转，服务拆分后更乱。
建言：微服务架构的技术门槛非常高，没有充裕的技术人员不要轻易入坑！
坑6：
如果把一个单体应用拆分成多个微服务后，部署时间是否真的会少呢？另外从描述来说，微服务对后期的运维会不会是个考验？
建言：服务池变多了，所以要有统一的服务治理平台。
坑7：
我看到文章里谈的微服务都是基于Java开发的系统模式！那么我想知道，是否python、go、c#语言的开发也一样可以做微服务模式呢？还是说目前都是Java开发项目，所以微服务都是研究Java程序的？
建言：有的，只不过go语言使用是最近几年火起来的，所以对应的服务化框架也是最近几年才开始慢慢为人熟知的
坑8：
目前在通过docker将利用dubbo+zookeeper架构的微服务项目容器化，遇到一个问题。服务注册到dubbo后，会显示端口为20880，那么如果将容器内的20880随机暴露在宿主机的话，消费者无法在宿主机中找到20880（因为暴露在主机的为其他端口），麻烦老师不吝赐教 分享下实解决方案。感谢。
建言：？
坑9：
从2016年开始使用微服务进行大规模系统改造，整个过程中最困扰大家的问题有很多。就个人经历来说，最复杂的莫过于服务的拆分。因为这是涉及整个系统服务设计的底层工作。但是往往因为服务拆分工作不好，反倒让微服务的能力和特点发挥不出来。
建言：其实这个没有什么绝对的正确标准，根据每家公司实际的情况决定
坑10：
1.微服务拆分的粒度，很有讲究，需要根据不同的业务情况作出不同粗细程度的区分。
2.拆分的方式:按照大模块（用户，订单，单品），还是细粒度的那个核心公共功能，还是受用户并发来拆分。
3.就是拆分的原则:什么一定可以拆，什么一定不可以拆。
4.不要为了拆分而拆分。
建言：拆分粒度要视业务具体情况以及团队人员规模决定。如果团队人员不多，拆分过多的服务，反而会管理不过来。
坑11：
应用微服务化是不是一定会造成系统的性能下降？单应用的架构拆分成微服务是不是可以先稍微大粒度的拆分，然后再进行服务细化
建言：一般来说经过网络传输都会造成性能有一定下降，不过还好可以控制在5ms以内，建议先进行大粒度的模块拆分。
坑12：
微服务网络这块的问题如何解决，像超时这种？
建言：……
坑13：
现在公司正在准备向微服务方向演进，但是因为功能过多，现在所有业务都是在一个包中，如果采用微服务进行模块拆分，则相应的微服务太多，对应的开发成本将会相应的增加，况且人手不足，不可能一个人维护几十个模块，并且这么多微服务需要一个统一的管理平台，目前并不具备，请问有什么解决方式呢？
建言:看公司开发人力吧，如果人力不足不要拆了。
坑14：
搞微服务的话最小规模团队要多少人呀？
建言：能力强的话十人以下就行，但大部分团队建议十人以下不要考虑了。
坑15：
自己虽然有一定的微服务项目经验，但是缺少系统化的理论知识，同时实践中应用的也比较浅。等着老师的分享，借着这个专栏提升一下自己。
建言：会当凌绝顶，一览众山小。
以上就是微服务的一些坑，管中窥豹，你准备放弃了吗？