记得最早做app大家都提lamp，学会这4个就完事
现在写个代码，做个系统，设计个架构高低得k8s一下，k8s一来，那链路追踪、微服务监控、服务发现、稳定性方案之类的哗哗的就来了，那多了这么多东西，除了显得高大上，吹牛逼外，实际上多了什么好处？
微服务的目的
我觉得就是2个点
- 解决复杂的业务：
- 业务涉及面比较广，一个或少量模块会让业务逻辑过于集中，使得代码越来越复杂，越来越庞大，耦合严重
- 在将要进行重构改造时会发现历史包袱特别重，很容易迁一发而动全身
- 稳定性不好，可能产生二级服务出问题拖垮一级服务的问题
- 扩容不方便，CPU密集型服务和io密集型服务对于扩容需求不一样
- 解决复杂的人：
- 参数业务的人数据太多，一个团队十几个人改同一个模块，可能会常常要去解冲突
- 不同的人不同的想法，一个模块很容易出现很多种不同风格的代码
- 代码互相耦合但又不互相负责，导致很容易带着别人的bug代码上线
微服务当前问题
-
有能力要微，没能力也要微
一些团队为了能解决好上面两个点，带入了微服务，但微服务又需要一整套链路才可以发挥一个好的作用，而这套架构需要一个完整的基础、运维团队来维护，这是一笔成本，不能在团队没有准备好的情况下强行带入微服务，否则业务线上的日志问题、监控问题、链路问题、治理问题都会疯狂打脸
-
只要微了就好了
不能因为开发有问题，就觉得引入微服务就能解掉一切问题，比如原来系统CPU占用高了，延迟大了，不知道咋办，先拆个微服务出来吧，老的先不管了，拆出来的这部分速度没问题就行。结果原来的问题还是问题，而且没准拆出来的过几天又成了另一坨屎代码
-
疯狂微，微上它100个
有个新功能，不知道放哪好，那就要起个新服务吧，我的团队之前就是这种情况，十几个人有着上百个微服务，大量服务无法解耦，上线一个功能可能要部署十几个服务，微了还不如不微，还存在着大量互相拷贝的代码
-
不知道为什么就是要微一下
也不知道为什么，大家都微了，我也得微一下。本来可能简单试验的项目，或者一个很独立的项目，没必要上来铺一个大摊子。或者我这东西就2个人做，拆几个服务反而把自己弄糊涂了
微不微？怎么微呢？
我觉得还是要看几个点
需要有能力管理一个k8s，不管是你个人还是团队，或者买服务提供商的方案，要清楚面临的问题
微服务的划分是非常重要的，要搞清楚你的业务是怎么一个结构，微服务切记不是越多越好，能够解耦的业务是一个重要前提，解耦我理解一个是业务解耦，一个是数据解耦。业务解耦代表你的服务可以完全闭包一个方向的业务，相互只有rpc数据协议，互相黑盒，比如直播以外的业务不需要关心哪些人可以直播，开播逻辑是怎么样的，某个用户在不在直播中，这就需要通过大量的rpc进行交互，同时怎么处理两个服务交互是一个需要考虑的点，比如你有一个直播服务，也有一个聊天服务，但在直播里面也可以聊天，聊天室里面也可以嵌入一个直播，那这两者之前交互部分就不能简单放在某一个服务里，这样就类似于一个base服务，一个业务服务。而数据解耦代表着各服务管理各自的数据，服务间的数据应该是不透明的，比如我需要查询一个用户数据，可能条件比较复杂，我觉得我自己查user表可能更方便灵活，但这样就会打破数据隔离，rpc的交互协议与原始数据并不一定是完全一致的，直接查别人表导致user表的变动会让你的服务也会有影响，使得user的变动成本非常高
人员数量及能力很重要，如果一个团队只有10个人，却分了上百个服务，一个人平均要管着十几个，那开发成本会奇高无比，单说上线就会比正常时间要拉长很多，哪怕业务量是一样的，1个人管1个服务和1个人管10个服务那肯定是不同的体验
