IcyFenix
IcyFenix
> @zhupishiye > 常规异常和业务异常都返回ConstraintViolationException统一处理，如果想区分两种异常来对用户不同展示方式，比如业务异常会提示用户详细原因，常规异常统一失败，怎么实现呢 不同的校验异常可以从ConstraintViolationException派生出不同的子类来表示，譬如SomeBizException extends ConstraintViolationException 对于需要自定义信息的异常，可以针对性地定义专用的异常处理器，譬如SomeBizExceptionExceptionHandler，在该处理器中返回与客户端约定的格式 同时注册一个“兜底”用的ConstraintViolationException统一异常处理器，对没有哪些没有专门定义的异常处理的派生至ConstraintViolationException的异常进行统一的处理
> @UUNNFLY > Bean Validation在controller层的函数入参上，那还不是发生在controller层吗，或者是controller之前？不过确实更容易复用，维护。 > 如果逻辑比较复杂，例如要根据客户端传参从数据库查出另一个值，然后再判断，若合法，这个值还要用在下面的步骤，如果也用Bean Validation就多了一次不必要的数据库查询 只是这里的演示代码拿了控制器的作为例子而已，Bean跨越了各个层次，验证的代码逻辑也不与任何一个层耦合，所以在哪里验证都是可行的、可选的。 譬如文中也举了个例子，Hibernate做持久化时也会进行验证，这就在DAL而不是在Controller中了。
> @pass、@PassOrPresent 应该是@past @PastOrPresent 感谢指正，已修改
> 图13-4的第四点是否少了一个“合”字 已修正，感谢。
> 【- ReadWriteOnce # 访问模式为RXO】 根据文中后面的解释应该是RWO 已修正，感谢。
> @dengchaoh > 周大哥，看到了您说的马太效应。再联想到之前您讲的软件涅槃，而完善的微服务体系允许服务有涅槃的过程，有强大的容错能力。微服务发展又如此迅猛，觉得马太效应真的不远。 > 我不禁对最需要掌握的技能进行了思考，并产生了更强的焦虑感。 > > 我是一名有七年工作经验的java开发工程师，28岁，目前在一家北京的传统信息软件技术公司，工资相对计算机行业偏低。 > 局限在java语言来说，jvm调优与并发编程等比较高阶的能力，是不是就很不关键了？ > jvm我读了您写的《深入理解Java虚拟机：JVM高级特性与最佳实践》的第二版与第三版，由于工作中鲜有机会实践，只停留在一些理论理解，而缺失实践，理论知识也会淡忘。 > 并发编程读过《Java并发编程实战》，对并发编程有些了解，也有一些实践，一般水平。 > 微服务公司并没有用起来，实践经验也缺少。远程调用、分布式事务、注册中心、配置中心、熔断、限流等知识，通过看视频跟您的这个文档有一些了解。 > java基础知识，经过这些年的磨练，是挺扎实了，spring能熟练使用。 > 常用设计模式有了解，也理解的比较到位。 > > 我不想沦为螺丝钉。 > 我应该提升自己的哪些能力呢？ > 这些年只是做到了胜任分配给自己的工作。 > 现在发现自己缺少前瞻性思考，缺少对自己职业生涯的把控。...
> @dengchaoh > 周大哥，我前几天看过了您的回复，我想我应该做深入学习，不止步于理解，应该深入下去，做更多的思考，再加上记录。 > 另外还想问您，您认为对一名程序员而言，最重要的内功心法是哪些？另外的另外，还想屁颠屁颠的追问下，您对修炼这些心法推荐的书籍。 文中说的，计算机课程中几乎所有带“原理”的课。 这些都有很经典的书：编译原理的[龙书](https://book.douban.com/subject/3296317/)，计算机体系结构和程序运行的[CSAPP](https://book.douban.com/subject/26912767/)，分布式与数据库原理的[DDIA](https://book.douban.com/subject/30329536/)、操作系统原理的[MOS](https://book.douban.com/subject/27096665/)，等等。这些书系统严谨全面，但可读性并不优秀，在B站/Coursera刷这些书作者们的公开课翻译视频也许是更好的方法。
> @Ahoo-Wang > > 系统的架构趋同于系统设计团队的沟通结构。 > > 周神，这句话的翻译应该是不准确的。 > 组织的沟通结构 ≠ 系统设计团队的沟通结构 > 在康威定律上下文中 组织的沟通结构这句话应该近似可以理解为企业的组织架构，而不应该是系统设计团队。 > > 所以根据康威定律，企业应用微服务拆分有一个很容易识别的边界就是组织结构。 > 好的，已修正。
> 烟囱式架构段落最后一句，“独立拆分”和“老死不相往来”中间是不是少了顿号？ 看来不是我一个有此问题。之前是有顿号的，但是校稿时语言文学专业的编辑MM教育我说，两个双引号中间不应该加顿号。
> @huangyongliang > 再次预言未来“无服务将会成为将会成为日后云计算的主流方式”；“也导致能函数会有冷启动时间”，好像有笔误。 谢谢，是有BUG，下次更新新文章时一并修改掉。