作者回复: http://www.infoq.com/cn/articles/micro-service-technology-stack,这是我发表在infoq上的文章《微服务技术栈开源选型手册》,可以参考
作者回复: 都可以,只是两种风格,保持一致性即可
作者回复: 有些rpc,例如grpc/thrift等支持契约式开发,通过契约IDL可以自动生成客户端,再用生成的强类型客户端写测试比较方便。我的经验,rpc接口除了通过client去测,也没有特别的方法。REST接口测试的工具和方法会更多一点。
作者回复: 统一异常处理比较难做到,业务场景团队各不相同,很难规范,一般由各个团队自治处理,组织层面架构师可以给出一些规范建议,然后采用ELK/CAT统一收集异常,进行集中监控和治理。
作者回复: 一些rpc框架如grpc或thrift支付契约驱动开发,直接有代码生成工具;restful框架如spring mvc支持swagger,可以用swagger生成服务端和客户端代码,可参考https://editor.swagger.io站点
作者回复: 微服务既可用rpc,也可以用rest,这只是两种调用风格,在业界大小公司都有众多成功落地案例。springcloud就是为微服务定制而生。当然具体是否合适还要看企业上下文(技术,团队,业务等)。
作者回复: 代码生成一般指根据服务契约(swagger/thrift/protobuf)生成客户端甚至服务端代码,可以规范化和简化服务开发。
作者回复: 推进不仅是技术问题,也是组织问题,需要有领导影响力的管理层和架构师,我的经验需架构委员会这样的虚拟组织主导+管理层支持推进。
作者回复: 不冲突,中心化和去中心化都需要治理,社会上人多了需要政府治理,微服务多了,同样需要治理,只是集中治理,还是去中心化治理(仍需配合部分集中式治理)
作者回复: 要看具体业务场景,业务痛点是什么,看改造能提供什么业务价值,然后小规模迁移试点看实际价值产出,再评估下一步计划
作者回复: rest/rpc都可以是同步或异步调用
作者回复: 返回错误码或者抛异常,只是两种设计风格,都可以,没有特别好坏一说,规范好保持一致即可