今天依旧以切实经历聊聊职场故事。
故事从一天午睡后说起，那时候我所在的公司系统基本成熟稳定，用户量不会有暴增的情况。虽然技术有点老旧，但那都是我们在曾经外包公司给的烂尾楼中抢救出来的代码。
给大家再介绍下我原本所在的这家公司是业务驱动的，明显是市场部门会更受到重视。而且是做少儿赛事，之前收发作品评分基本都没在线上。大老板为了跟上互联网时代，拍脑袋成立了技术部门。
眼看他高楼起眼看他高楼塌，大老板看到技术部每天也没什么业务，市场谈完了学校用户量暴增之后就系统瘫痪，又想拯救系统又打着裁员的注意。老板人脉广，听了外面的“技术大牛”玩起来概念了，回来就给普及微服务。
接受任务
把多年的老系统（用户量本来就是按照几万设计的）要搞成几百万人使用的承载量。把多年的核心系统改成微服务，一个会议几个小时下来就开始接受微服务了。
什么是微服务？
微服务大家一致众说纷纭，系统架构设计一直各个公司不断优化的点。也是构建一个系统最核心的部分。微服务是把一个整套复杂的业务逻辑拆分成多个简单的业务，用模块化去实现组合的。
听起来都挺好，概念层也说的过去。但是每一个模块的开发都需要巨大成本。
开发工程师接口设计变多了，打开多个工程，吊事要部署多个程序，提测试的时候要多个包；
测试成本也增加了，测试要部署多个环境，准备多个微服务数据，测试接口更多。
运维也麻烦了，每次上线要操作很多个微服务，每一个微服务之间还有一来关系。
调用链太长，性能下降。
而且如果没有自动化支撑，交付任务是很慢的，不说测试和逐台部署了，就说每次故障定位都要查各种状态和日志。如果你公司的规模小，那完了。你说可以引入DevOps，公司有钱还好，技术人员可以外招，就DevOps本身搭建有需要花费一大堆钱。
微服务成功案例
上面说了这么多坑，基本上是针对于自家公司的情况。字节其实给我们做了个好的示范，头条80%的流量跑在Go服务上，微服务数量超过个。高峰的时候QPS到万。日处理请求超过三千亿。
从事开发十余年，眼看着框架从EJB到Struts+EJB，然后是SSH到SSM，再到SpringBoot。框架越来越好用，开发越来越简单，代码越写越少，但是架构越来越复杂。就目前现状看来中小型公司依旧不适合微服务，如果一个人就专注一件事还好，但是规模不大的公司一个做很多事情的时候，微服务很折磨人。
对于构建微服务系统的建议
首先肯定是没有想好怎么拆就不要拆；
有完整清晰的迭代路线再执行；
如果团队没有业务专家，尽量不要去做，因为难以避免面向数据的微服务开发；
其次就是成熟的配套设施、容器环境、鉴权网关等。
欲知我们后来微服务了没，怎么做到的？欢迎