最近的评论

• 评论了主题 请问githup引入 是怎么安装的？
  go get -u -v github.com/Shopify/sarama 如果执行没报错，那就安装成功了
• 评论了主题 Go指南_切片就像数组的引用_结果困惑
  `b := names[1:3]` 这行代码对names进行了重新切片，切片的结果 b 是从names的 1 号元素开始，到 3 号元素结束(注意不包含3号元素) 所以 b[0] 其实就是 names[1]，对应的值是 Paul
• 评论了主题 我擦，GO编译的程序 直接用notepad++可以查看很多字符串和函数名
  这是正常情况，不仅是用GO会这样，编译成二进制执行文件的一般都这样。常量都是存储在常量区的，没有特别的加密需求一般都是存原始值。不仅Windows 的 PE 格式这样，Linux 的 ELF 格式也这样 如果你对二进制文件有保密性要求，你可以加壳。
• 评论了主题 代码部署问题，如果实现平滑重启
  这个不是go语言的问题，是所有二进制执行文件发布的应用程序都会遇到的问题。所有二进制可执行文件形式发布的应用程序，不杀进程重启的话是没办法更新到最新的版本的。 不杀进程重启的话，覆盖执行文件是能覆盖的，但是覆盖了也没用，因为内存中进程运行的还是旧的执行文件。 平滑重启的目的是为了尽量少或者不影响用户的访问，让服务器没有拒绝响应期，这个本质上要靠架构设计来解决。 如果是单进程的服务结构， 从设计上将单个进程拆分掉，比如拆分成 master 和 worker 进程，master 负责管理和维护 worker，并且向 worker 投递用户请求。当需要重启时，master 启动更新后的执行文件作为新的 worker1 进程，在启动期间的用户请求仍然投递给老的 worker 进程。 worker1 进程启动完成可以执行用户业务逻辑之后向 master 报告，这时 master 讲用户请求投递切换给 worker1 进程，然后关闭老的 worker 进程。 如果本来就是多进程或者多台服务器的集群方案，由 master 进程来管理多个业务逻辑进程，或者用户网关+消息队列来实现多个业务逻辑服务器之间的动态分配。当需要更新时，轮流对业务逻辑进程或者业务逻辑服务器进行更新并重启，这样从用户侧是感受不到的。中间存在灰度期，一部分用户的业务在旧的业务逻辑中运行，一部分用户在新的业务逻辑中进行，这要求业务逻辑的设计必须兼容性好，能够同时兼容这两种情况。 不管怎么样的架构设计，体系中总是有一些部分是不会被重启，始终运行的
• 评论了主题 go指针与C++指针用法不同，按哪个语言的用法用指针，请问如何抉择？
  Go 编译器支持逃逸分析，编译期发现一个局部变量的指针被外部使用了，就会在堆里而不是栈里分配内存。 不习惯就不要这么用呗，Go只是允许这么用，又没说必须这么用