加载中
回复 @慢慢来_ : https://my.oschina.net/huangyong/blog/158360
@黄勇
已知: 1.包名(例如:com.example.entity) 2.注解名 @Entity 求解: 获取com.e...
黄勇 2018/05/14 12:01 评论了博客:打造高效研发团队 (1) —— 组织架构篇
职能团队存在的意义在于帮助队员成长,不是汇报,而是培养,培训只是其中一种形式,更重要的是帮助队员完成所指定的 OKR,这部分我将在第三篇中详细描述。感谢留言,期待交流。
@黄勇
2015 年,我加入特赞,带领了一支小规模研发团队。那时公司还在天使轮,团队最大的目标是能让产品上线,并证明我们的...
黄勇 2018/01/23 16:10 回答了问题: 关于动态创建servlet的疑惑

抱歉,长期未回复您的问题,现在解决了吗?可以参考本书附带的源码,该源码均已跑通。

@琉璃糖
@黄勇 你好,想跟你请教个问题: 黄老师,你好,我最近在拜读您的从0开始写javaweb框架,有一个问题不是很明白...
黄勇 2018/01/23 16:08 评论了博客:Smart Framework:轻量级 Java Web 框架
回复 @zhangwdcdd : 确实需要好好改进,多谢您的建议。
@黄勇
工作闲暇之余,我开发了一款轻量级 Java Web 框架 —— Smart Framework。开发该框架是为了:...
黄勇 2018/01/23 16:04 评论了博客:Proxy 那点事儿
回复 @somhu : 当然可以
@黄勇
Proxy,也就是“代理”了。意思就是,你不用去做,别人代替你去处理。比如说:赚钱方面,我就是我老婆的 Proxy...
黄勇 2018/01/23 16:02 评论了博客:3种使用MQ实现分布式事务的方式
赞!
@温安适
1.保证消息传递与一致性1.1生产者确保消息自主性当生产者发送一条消息时,它必须完成他的所有业务操作。如下图:这保...
黄勇 2017/11/03 15:01 回答了问题: 微服务如何设计公共组件库
回复 @公孙二狗 : 这些就不是服务,这样的代码应该在数据框架层面或者公共组件库中。
@learn_more
@黄勇 老师你好,请教您一个问题,希望能够得到您的解答。微服务提倡各个服务独立,互不依赖,甚至提倡各个微服务之间的...
黄勇 2017/11/02 18:52 回答了问题: 微服务如何设计公共组件库

@learn_more 赞!

@learn_more
@黄勇 老师你好,请教您一个问题,希望能够得到您的解答。微服务提倡各个服务独立,互不依赖,甚至提倡各个微服务之间的...
黄勇 2017/11/02 16:33 回答了问题: 微服务如何设计公共组件库

问题非常好!

微服务架构也有一个不断演化的过程,优雅的架构不是一天形成的,牛逼的架构也未必适合现在的应用场景,架构是随着业务不断变化和升级的。

对于你说到的代码重用问题而言,如果我们将这些代码做成公共包(jar 包),再让其他服务依赖它,这样重用问题似乎解决了,但却引发了其他新的问题,当我们升级这个 jar 包,需要发布所有依赖它的服务。那么反过来说,代码不重用,真的就是目前遇到最大的问题吗?如果不是,为什么要考虑代码重用问题,而不是其他更加重要的问题?比如:让服务合理切分并分工,从而提高团队工作效率。

我的建议是:公共组件可以有,但绝不要做到服务内部依赖(jar 包依赖),而要做到服务间通信(rpc 调用),将公共组件做成公共服务,当我们发布一个公共服务时,无需发布其他服务。

补充:对于和业务不相关,并且变化较少的公共代码,不妨可以考虑做成公共 jar 包,毕竟它不会经常发布。

@learn_more
@黄勇 老师你好,请教您一个问题,希望能够得到您的解答。微服务提倡各个服务独立,互不依赖,甚至提倡各个微服务之间的...
回复 @跳蚤 : 1. 服务之间的调用一般可用 RPC 进行通信,此时无需服务网管,直接在客户端进行服务发现即可。 2. 不一定要用 HTTP,但最好协议上能统一,这样服务网关处理起来比较容易。
@局长
很久没做过关于微服务的高手问答了,时隔一年,我们再次邀请到了黄勇老师,OSCHINA 本期高手问答(10 月 18...
1. 该问题超出本期话题讨论范围,有兴趣我们可以私聊。 2. 同上。 3. 我们自建的自动化测试框架,主要针对微服务 API 进行测试。 4. 本书下册有7章。
@局长
很久没做过关于微服务的高手问答了,时隔一年,我们再次邀请到了黄勇老师,OSCHINA 本期高手问答(10 月 18...
1. 除非有特殊安全性要求,服务之间的调用一般不会做数据加密处理,毕竟在都是在内网中通信。 2. 在 Event 表中存放对象操作之前的状态,用于事务补偿。 3. 抱歉,这个问题无法回答。 4. 5年开发属于高级水平,可考虑带团队,转型技术管理。 5. 这方面还需要更多的积累,希望在不久将来可以尝试写一本这样的书。
@局长
很久没做过关于微服务的高手问答了,时隔一年,我们再次邀请到了黄勇老师,OSCHINA 本期高手问答(10 月 18...
服务拆分的一个重要的原则是:先粗后细。也就是说,一开始拆分服务边界时,不要完美地追求细粒度,只需确保服务之间边界是清晰的,耦合程度较低即可。随着我们后续对业务的不断深入理解,才有能力将目前粒度较粗的服务,逐渐切分为粒度更细的服务。实际上,业务是不断变化的,我们的架构也需要不断变化,这样才能真正做到“拥抱变化”。
@局长
很久没做过关于微服务的高手问答了,时隔一年,我们再次邀请到了黄勇老师,OSCHINA 本期高手问答(10 月 18...
用 Docker 能够很好地封装并隔离微服务,也能对持续交付有本质的改善,至于是否需要使用 K8S,需要慎重考虑,如果服务数量不太庞大的情况下,建议使用 Docker 自带的 Swarm 模式也许就能实现我们的需求。
@局长
很久没做过关于微服务的高手问答了,时隔一年,我们再次邀请到了黄勇老师,OSCHINA 本期高手问答(10 月 18...

没有更多内容

加载失败,请刷新页面

返回顶部
顶部