引言：扇贝 2017 服务端技术回顾

随着流量的提升，团队的壮大，为了适应变化，2017年，我们的服务端进行了比较大的改造，全面拥抱了微服务，容器编排等。

从而很大程度上提高了开发效率，降低了维护成本。

这期间，我们碰到了很多难题，走了不少弯路，也积累了比较丰富的经验。我们希望这些经验和解决方案能够给中小型的互联网公司带来启发。

微服务

网上有很多微服务的科普和介绍，这里从实践角度讲一点我们的心得：

1. 微服务的设计不光是技术问题，更是人的问题。理想的状态是微服务都有对应的团队持续开发，调优和维护。所以反过来讲，团队的规模和组织模式也会影响微服务的切分。
2. 微服务一定要有规划，分层，分组。例如哪些是基础型服务，哪些是业务型服务，哪些是边界服务(直接接受公网流量的)，哪些是内部服务(不暴露在公网上)。
3. 微服务要采用 devops 模式，否则运维很可能成为瓶颈。每个微服务的技术团队都要有从开发到部署到维护的所有权限。
4. 微服务的服务治理非常重要，一定要舍得投入成本。包括：监控报警，日志收集，服务发现，健康检查，熔断等等。

关于这些方面的具体实践，我们后面的文章会再跟大家分享。

容器编排和 service mesh

关于容器编排，这两年技术圈一直很火。很多公司都从传统的运维架构迁到了基于容器编排技术的新架构上来。

在之前，出于团队和技术的考虑，我们只是将服务的运行环境容器化(用docker来封装运行环境)。
随着 2017年 kubernetes 成为了容器编排领域的事实标准，我们也开始将微服务大规模迁移到 kubernetes 上。

除了 kubernetes 以外，还要解决的就是服务治理问题。
市面上有以 SpringCloud 为代表的多个语言特异的微服务框架；也有以 linkerd 为代表的 service mesh 解决方案。

我们采用了 service mesh的方案。因为我们觉得一来实现了跨语言跨框架的通用服务治理方案，二来service mesh 是未来的趋势。

当然由于目前的service mesh方案很多还不成熟，很多问题需要深入源码甚至二次开发来解决。这些我们也会在后续的文章中给大家来慢慢分享我们的方案，以及开源一些我们用于生产环境的项目。

Open Source

我们是开源项目的受益者，所以我们也致力于力所能及之处，回馈一些能够帮助到他人的开源项目。这些项目也许不成熟不完善，但是能解决阶段性的问题。在扇贝，正是他们帮助我们的工程师构建起了支撑百万级日活，十亿级日请求量的产品。后面的文章里，我们会结合微服务，容器编排和service mesh给大家做详细介绍。

作为引言，也是一个大纲。我们会不断更新文中提到的内容，感谢关注扇贝技术团队

---

欢迎关注我们的 知乎专栏：扇贝技术架构小组