记第一次离职

Author: Cooooing

source/_posts/记第一次离职.md

@@ -27,7 +27,7 @@ categories:
 为了适应工作，肯定会多去学习。但随着工作的深入，如果不是有兴趣支持，这份热情很快就会消磨。（当兴趣爱好成为工作，很容易消磨掉兴趣。肯定有人说过不要将兴趣爱好当成工作的话
 
 话说回来，当时在看 Kafka（也记了两篇笔记）。**他和我说的另一个主题大概就是要关注架构层面的设计，使用层面都差不多，就是如何使用API，看着文档很快就能上手。**
-这个怎么说呢，我觉得架构层面需要服务具体的业务，就跟并发编程一样，需要长时间的运行才能暴露出足够多的问题。
+这个怎么说呢，我觉得架构层面需要服务具体的业务，同时也跟并发编程一样，需要长时间的运行才能暴露出足够多的问题。
 但更加关注架构层面肯定也是没有问题的，和并发编程一样，思考各种可能出现的情况，会有什么问题，怎么解决。
 架构层面其实很难离开分布式和微服务，虽然我认为大部分公司单体的架构已经足够使用。
 这些都多少会影响我后面的学习方向，go的学习应该是很早之前了，真正想java转go可能只是今年年初。但语言只是微不足道的一部分...（这里省略吧，后续的方向暂时还没有想好
@@ -39,7 +39,7 @@ categories:
 spring是个非常厉害的框架，它的抽象程度也是非常之高（当初还去读源码，太不自量力了）。它将系统配置、拓展性等大部分业务无关的复杂度都隐藏在了框架内部，使得对业务的开发变得非常简单，关注的点也非常少。
 
 新同事是三年经验的go开发，最近和他的话题主要在 go、docker 和 kubernetes。
-今天下班的路上，也许是看出了我的迷茫，跟我说了一些云原生的方向。kubernetes、服务网格 istio、链路之类的东西，都在在各方向之中。
+今天下班的路上，也许是看出了我的迷茫，跟我说了一些云原生的方向。kubernetes、服务网格 istio、链路之类的东西，都在云原生方向之中。
 看来 kubernetes 是要深度使用的了，虽然我觉得大部分业务都用不上。我现在倒是更倾向单体架构，到单机扛不住的时候可以上分布式（这个需要单体开发时就注意分布式部分，否则改造会比较麻烦），到分布式服务太多运维管理上顶不住的时候才是上kubernetes的时候。
 倒也是符合架构的发展历史，不管是架构还是框架、中间件都是为了解决对应具体问题而出现的解决方案。分布式与微服务还是有区别的，微服务大概就是服务划分、拆分之后的各种服务的分布式，服务间的依赖通过rpc解耦。（描述得比较抽象了