stack-labs / notice Goto Github PK

经过2019年一年的探索，我们创建了Micro**站Github社区，也在准备开发自己的产品。

新的一年中，我的想法是我们会提供更全面的文档，覆盖面更广的教程，花更多的精力在源码贡献与解读上。

2020我们的工作重心主要在以下几个方面：

1. 提供生产级、运维级的项目。生产级体现在设计、安全、事务（含分布式）、灰度、蓝绿（含染色等），运维级集中在部署（虚拟化、非虚拟化、持续）、监控、追踪等

2. 重新编写文档，更符合国人的阅读与学习习惯

3. 编写手册，手册与文档不同，文档着重使用与特性介绍。手册会与文档有部分重叠，但是更倾向于像书本一样的由浅入深，也会涉及原理介绍等等

4. 定期发布视频，视频与文档配合，可以提高学习效率。

5. 微信公众号上推送更多更好的资源，这块会与博客同步。

6. 尽可能提供技术支持

以上目标会有微调或增加，目标都是为了能够让大家能有更多的选择，对Go-Micro有更深的理解。

1. Micro In CN的源出发点

早期我们的想法是围绕Go-Micro体系构建一套完整的资源站点，后来发现这样做太单一，且资源的用户覆盖面永远只会在Go-Micro中，而微服务本身不只有一个框架，就目录Go语言体系而言，至少有go-kit, go-micro, rpcx, dubbo-go, go-zero等，那为什么不牵手起来共建呢？

这些微服务永远绕不开的话题，比如注册发现，均衡，安全拦截，分布式任务，持久化存储等等都是通用的。

2. 放一起有什么好处

大家在对比框架时往往要自己去各大官网找，然后自己搭建然后跑起来对比，没有一个统一的站点把大家关注的点全部整合起来，让大家按需索取，有的开发者需要易用性，有些需要简洁，有的喜欢性能。

而大家自己的搭建的对比示例往往因为不擅长不熟悉导致测试点对比不完整、不公平。

3. 统一的样子

3.1 社区入口门户统一

github仓库基于重命名后的micro-in-cn来维护，也即是在现有的基础上，把现有的仓库升级改版，完成不针对特定框架的命名与布局。

3.1.1 重命名本社区

待讨论，见

3.1.2 域名与Logo

目前使用的是microhq.cn域名，不太合适合并后的社区入口了。

待讨论...

3.1.3 社区化进程

3.1.4 重构教程模块

Tutorials 模块目前只针对Go-Micro体系构建，需要为不同框架创建目录。

3.2 各框架专属模块

3.3 核心团队与持续性输出

3.4 讨论模块

[持续更新中，欢迎讨论]