CITA hin棒棒，既然都微服务了有没有搞大的想法，直接抽象一套rust的微服务框架粗来，大家说吼不吼啊，我举双手资瓷，恩恩。
cita的一点不成熟的想法
2赞
非常好的主意！！你觉得抽象出来的微服务框架应该具有哪些特性呢？
框架自然是极好的。如果作为需求者，这个框架的特点会是神马呢？倾听ing
是好主意，要支持什么特性呢？
无法同时回复楼上各位大佬，基于大家问题几乎是同一个（真的不是管理员的多个马甲吗？） ，在这里统一回复：
基于对Rust的理解尚浅，无法提出在针对Rust本身提出足够好的建议，所以仅从个人使用Spring Cloud和Dubbo的体验来说：
可以分三个阶段来开发：
阶段1 rpc通信框架，带流量监控和管理（限流）
阶段2 支持主流协议定制化，周边生态组件完善（目前来看CITA已经有了大部分，rust版本的各种中心，消息队列，链路监控，注册中心，），比如一些rpc协议，我最近在关注RSocket，不知道rust支持异步响应式怎么样，如果可以的话，个人感觉这是个趋势，因为据说Spring接下里会把RSocket作为官方协议整合进去。
阶段3 针对微服务的一些痛点提供硬核解决方案，比如链路压测，数据治理等一些问题提供rust版本的框架。
本人菜鸟一枚，不妥之处请各位大佬轻拍，愿意为CITA社区繁荣而尽一份力。
2赞
you know too much～ 
啊，不要，我什么都不知道
非常感谢你的想法啊！说明你具有很长远的眼光！！
我们应该可以看到现在CITA其实在微服务这条路上还有一些路要走。比如说：
- 我们还做不到将CITA某个微服务进行自动化多实例，以通过添加物理机器的方式来获取处理能力的线性提升。
- CITA中的各个微服务在集群环境下还不太好。现在我们是把整个CITA把包成一个镜像放到docker下执行；按照微服务的思路，是可以把每个微服务单独一个镜像，在集群下可以各自自动多实例执行，以应对应用业务量的变化。
在目前我们区块链的应用业务量还没有上来的时候，其实现在单机跑CITA就能应付，但随着业务的爆增，CITA理应具备水平扩展的能力，通过采用集群来跑一个CITA节点来提供业务处理性能。
- 在rpc通信框架上，Rust有一些组件，如grpc-rust, ping cap grpc, tower-grpc。现在pingcap好像也选择了tower-grpc.
- 在微服务框架上，我们有考虑过service-mash, 像Linkerd 和Istio。
- 第三个问题我还没有细想。
另外，我们不是管理员，也不是马甲。
2赞
已赞，感谢大佬这么认真的回复
引用 我们还做不到将CITA某个微服务进行自动化多实例，以通过添加物理机器的方式来获取处理能力的线性提升。
这点应该是交给K8S通过服务治理配置来负责，包括均衡负载，所谓DevOps，只要服务间标准和规范统一好，应该是问题不大。
引用 CITA中的各个微服务在集群环境下还不太好。现在我们是把整个CITA把包成一个镜像放到docker下执行；按照微服务的思路，是可以把每个微服务单独一个镜像，在集群下可以各自自动多实例执行，以应对应用业务量的变化。
这个我明白，毕竟你们项目那么多，我觉得这个目前只是你们没精力做拆分吧，我觉得拆成独立节点分别部署主要是从性能上考虑，哪些单独部署，哪些作为插件形式打包部署。至于自动多实例的问题，同上。
非常棒棒啊，我去关注一波tower-grpc, Linkerd 貌似已废， Istio 扶不起的太子，尽管如此mesh趋势基本已定了吧。
引用 另外，我们不是管理员，也不是马甲。
开心啊，论坛虽小，大佬巨多啊，以后我要经常来。
最后，这小哥不是CEO吗，这么会说话，前途无量前途无量
1赞
linkerd2.0你有关注过吗？我看了一下他们的github，代码提交还挺活跃的。
linker2.0的proxy是用rust写的，性能感觉应该不错。
好吧，我没追，只是看了新闻说官方团队表态是为了维护而开发的项目就直接放弃关注了
这点还挺需要的，前面两个开发同学瞅瞅。