2019-11-13微服务化之后一些读库操作变成了远程调用，很多多次读的操作都要修改为批量读取来减少网络耗时，这里的改动还是很大的，甚至一些要求响应时间很高的，还需要做本地缓存/作者回复: 是的
1 8
2019-11-15老师好，我们在做微服务项目的时候。碰到最难受的问题就是:比如一个流程要调用三四个服务，前两个调用成功了，第三个失败了。类似的这种情况，该怎么处理呢？作者回复: 这个只能保证最终一致性，比如如果有失败的，想办法把数据修复
2 5
2019-11-13微服务拆分的原则:
原则一，做到单一服务内部功能的高内聚，和低耦合
原则二，你需要关注服务拆分的粒度，先粗略拆分，再逐渐细化。
原则三，拆分的过程，要尽量避免影响产品的日常功能迭代，也就是说，要一边做产品功能迭代，一边完成服务化拆分。
原则四，服务接口的定义要具备可扩展性。 5
2019-11-13服务接口修改版本号问题；服务间的循环依赖问题；传输协议的选型很重要，因为牵扯到序列化问题；链路追踪能及时发现报错日志；点太多啦：） 3
2019-11-13然后想问下老师，就是我们的用户服务也是单独分出来了，有的内容放在了缓存里面了，但是目前除了去调用用户服务的接口获得数据外，有的时候是直接在其他服务里面调用用户的redis里面的数据的，感觉这样比较快，比调用接口快，然后想问下，按照微服务的话，这种放在缓存供其他服务调用是合理的吗？是不是最好还是缓存也分开，然后每次都得调用接口，然后接口里面调用缓存会比较好啊，希望老师解答，谢谢老师作者回复: 这样不太好，服务依赖的资源最好不要和其他服务共享，否则一旦这个资源变更了，我们很可能会漏掉其他服务；再有就是如果其他服务对这个资源有不当的使用，那么也会影响到你的服务
2 2
2020-01-05两个披萨就够我一个人吃。老外一个个人高马大的，胃口咋那么小。作者回复: 这个有时间要问问老贝了：）
1
2019-12-08反驳一点，用户相关的数据有时需要冗余到本服务，跨项目有时查点数据很蛋疼，或者说加点接口，用户服务要排期，如果是冗余到自己的服务，随便加接口。
其次改接口成4个参数的时候，应该加个过期注解，保留旧的接口兼容旧的调用，让他们慢慢迁移，然后新增新的接口来实现新的逻辑。其次还有maven的快照版本跟正式版本来解决，虽然我没有去了解过，哈哈 1 1
2020-01-15老师，问下文中说的 用户服务 和 内容服务 那里，对于内容服务内容的获取鉴权的过程，每次请求都先去用户服务那边判断是否有权限，有权限再走内容服务 没权限直接返回，而 内容服务只是获取内容 不做任何鉴权 这样做可以吗？作者回复: 我觉得是可以的
- 2019-12-30微服务化后事物该怎么处理？
作者回复: 事务的场景不多吧
2019-12-29老师，微服务各子项目的端口设置为随机端口，目前能想到的是在维护上可能比较难。那么随机端口还会造成其他问题吗？作者回复: 额 为啥要随机端口呢
2019-11-20感觉微服务的拆分像极了面向对象中的类的划分。
2019-11-20想问下老师如何拆分数据库又不影响日常功能迭代的？ 是该先拆工程还是先拆数据库呢？作者回复: 一般先拆数据库
2019-11-18公司现在的项目，用的应该是老师说的折中方法，拆分了很多子模块，但是模块与模块的依赖比较严重，像资源模块，作为基础模块，其他模块基本都要用到这模块的表，老师关于这个，针对这个依赖情况，您有什么好建议吗？如何做到高内聚低耦合
2019-11-14打开。wow，这节课似乎学到不少。
1. 从认证用户这个例子，联想到分层架构思想，即便有些很简单的逻辑，也不宜越级实现，否则后期维护的时候分散得到处都是。
2. 服务接口的参数类型最好是封装类
3. “康威定律”听起来很有道理
4. 我们团队监控调用链使用的是 pinpoint
5. 拆分工程jar包依赖我们也做，采用maven来互相引入，不过也容易出现改动后编译期就出问题，不如微服务运行时来的纯粹。展开
2019-11-14“团队按照业务边界划分”，这个是非常必要的，如果没有对应的人负责，拆分的“高内聚，低耦合”根本无从谈起
2019-11-14老师阅读开源框架源码这块你们是怎么进行的，理清架构和分析架构开发思想，读开源的源代码我想要的是人家是怎么设计使用利用设计模式反射等开发出来的框架的，我理解学会了可以学习借鉴自己应用到实践中，但苦于看源码有些不懂的，该怎么进行呢作者回复: 我的做法一般是把源代码下载下来先把它运行起来，然后想一想它解决的是什么问题，再根据问题来调试代码
1- 2019-11-13刚进公司的时候就是使用的微服务，结合文章的内容，我觉得我们团队在遇到故障之后的问题追踪方面还可以加强下， 1
2019-11-13我又回来啦，老师作者回复: 欢迎~
2019-11-13我们一开始是按照页面功能进行拆分的，感觉拆的太细了，后来又按照业务合并了一些服务。
服务如果拆的太多，一旦修改了接口，沟通成本还是很高的。
2019-11-13微服务拆分以后最大的问题是故障的排查与定位问题。作者回复: 是的