ketchup 申请加入NCC

[phil-guo]

ketchup （番茄酱） 是一个基于dotnet core的微服务框架。通讯组件由高可用的grpc组成，注册中心为consul，采用轮询、随机、加权随机的负载均衡策略，并提供一个兼容kong的网关。
项目主页：https://github.com/simple-gr/ketchup
文档：https://github.com/simple-gr/ketchup/wiki
作者：simple
开源协议：MIT

--------------- 请根据加入要求填写以下项 ---------------------------------

• 1、项目基于.NET 技术（包括且不仅限于 .NET Standard 与 .NET Core）；
• 2、项目具有明确的提交记录（git commit log）；
• 3、项目具有相当覆盖率的单元测试；
• 4、项目具有一定的跑分数据；对于基础设施类项目，本款应满足；
• 5、项目创建时间距推荐时间应至少三个自然月；
• 6、项目团队核心开发者应在距申请时间一个自然月内对项目作有效贡献；
• 7、项目官档优先托管于 GitHub；
• 8、项目官档的星数不少于 100 颗；
• 9、项目应具备较完整的资料：
  • 9.1）README，具有国际化的 README 更佳
  • 9.2）文档或 Wiki
  • 9.3）示例代码
  • 9.4）项目发展路线图（Roadmap）
  • 9.5）其它可选项：网站、博客、手册、教程或出版物
• 10、项目应该具备较可靠的技术支持与响应能力：
  • 10.1）较有效的 issue 响应
  • 10.2）其它可选项：社区、邮件组、群组及其它社交媒体渠道等
• 11、项目具有较明确的发展规划和路线图（Roadmap）
• 12、项目未接受过商业公司或组织的赞助，也未有企业为项目支付费用
  • 12.1）企业开发的开源项目例外
  • 12.2）具有收费版本的开源项目的，其免费版本例外
  • 12.3）项目团队向第三方提供与该项目相关的有偿咨询类服务的例外
• 13、项目无版权问题，并满足「社区项目版权与开源许可证规定」中有关版权的规定；
• 14、项目应使用开源软件许可证，并满足「社区项目

[fanliang11]

市面上开源的99%都不是微服务，很多人不能理解微服务这个思想，大家都认为业务的细分成细粒度的服务就是微服务了，如果不能针对于组件可扩展，可替换， 那么只能定位为服务治理框架。就比如你的框架只能依赖于grpc, 而不能扩展替换thrift, dotnetty 等其它类型的通信组件，那么你的框架只能定位RPC服务治理框架
如果你涉及的是微服务，根本不需要集成kong网关，因为微服务需要自研服务发现，服务治理。通过灵活配置可以达到灵活可靠性传输，而微服务需要提供针对于http协议的网关，走内部的服务发现和治理。 通过以上描述，提出以下意见

1. 建议可扩展替换各种类型的RPC组件
2. 建议扩展协议主机，支持各种协议扩展
3. 建议扩展基于http 协议组件，比如swagger, 网关
4. 建议支持远程传输拦截，过滤器
   如果能构建支持多语言，组合多语言混合异构框架，就更好了。
   以上是个人意见，不代表NCC意见，如果觉得说的不对，请略过。

[phil-guo]

你的建议非常好，我会仔细考虑。谢谢您的建议

…

------------------&nbsp;原始邮件&nbsp;------------------ 发件人: "fanliang11"<notifications@github.com&gt;; 发送时间: 2020年12月23日(星期三) 中午11:01 收件人: "dotnetcore/Home"<Home@noreply.github.com&gt;; 抄送: "alangur"<1228115857@qq.com&gt;; "Author"<author@noreply.github.com&gt;; 主题: Re: [dotnetcore/Home] ketchup 申请加入NCC (#48) 市面上开源的99%都不是微服务，很多人不能理解微服务这个思想，大家都认为业务的细分成细粒度的服务就是微服务了，如果不能针对于组件可扩展，可替换， 那么只能定位为服务治理框架。就比如你的框架只能依赖于grpc, 而不能扩展替换thrift, dotnetty 等其它类型的通信组件，那么你的框架只能定位RPC服务治理框架 如果你涉及的是微服务，根本不需要集成kong网关，因为微服务需要自研服务发现，服务治理。通过灵活配置可以达到灵活可靠性传输，而微服务需要提供针对于http协议的网关，走内部的服务发现和治理。 通过以上描述，提出以下意见 建议可扩展替换各种类型的RPC组件 建议扩展协议主机，支持各种协议扩展 建议扩展基于http 协议组件，比如swagger, 网关 建议支持远程传输拦截，过滤器 如果能构建支持多语言组合多语言混合异构框架，就更好了。 以上是个人意见，不代表NCC意见，如果觉得说的不对，请略过。 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[yang-xiaodong]

Hello, 感谢你的申请，请根据加入要求补充需要填写的项。

[phil-guo]

Hello, 感谢你的申请，请根据加入要求补充需要填写的项。

我已勾选上面所需的选项，这样是否可以完成这个工作？