首页手记微服务与云原生，你真的需要吗？还需要学、需要懂吗？

微服务与云原生，你真的需要吗？还需要学、需要懂吗？

标签：

Go 架构微服务

什么是微服务、云原生，它们的特点以及优缺点，关于系统架构的发展和演进等等，这里就不再赘述了，有需要的同学可以直走 yifan-online.com。

这里，咱们直接讨论两个问题：
一个是，你真的需要微服务与云原生吗？
一个是你需要学、需要懂这些技术吗？

先说结论：

问题一，不一定需要。

微服务和云原生架构，在大的公司和团队，是一定需要的。

中小规模的公司和团队也越来越多的在应用了。

规模很小的团队，业务还很简单的公司，则不那么需要微服务和云原生。

问题二，一定要学、要会。

不论你是否需要和使用它们，你都应该立刻马上去学和掌握它们。

我们不可能一直停留在微小公司和团队的状态，即使眼前没有需求，但是技术发展以及业务变化，或者是个人职业选择，咱们都需要学会和掌握微服务和云原生架构。

下面用两个经历来详细聊一聊这两个问题，大家可以更加容易的来理解。

1 大公司，业务多，团队多，技术栈繁多

在使用微服务和云原生之前的状态：

新产品开发，需要申请开发、测试、线上的各种资源，配置和验证服务环境，这一个基本的过程每次都要消耗一周以上的时间。
现有产品的发布，由于项目代码的影响面非常大，每次的上线前和上线后的覆盖行测试都非常累，提心吊胆，哪怕是很小的改动，都怕触发了隐藏 bug，导致其它的功能出现罢工。
尤其是出现资源变更时，比如：机房的搬迁，服务器故障，需要增加新的机房和更多的服务器时，又是一个巨大的工程，开发、测试和运维同学有需要有专人好几天才可能搞定。
技术栈方面，各种服务器的软件、组件、服务的依赖，更是让运维同学忙得不亦乐乎，也导致服务器很难做到通用和共用。慢慢的，需要维护很多的服务器集群。
业务和团队规模的变化，需要传承交接和完善的资料、文档也会很棘手。团队间的协作，同样是困难重重，很多时候都需要成里专项组来维护系统间的协作和互通，代价巨大。

大家对照着看下，自己所在的公司和团队，是否还有出现上面的这些情况呢？

在公司采用微服务和云原生架构之后，上面的问题是否都完美解决呢？又是怎样一种状态呢？其中有需要做那些事情，投入更多在哪些方面呢？

devops 以及微服务平台，简化开发、测试、线上的各种环境依赖。容器化技术让服务器环境标准化，新增加服务器资源时，再也不用担心环境的差异了。
微服务拆分之后，每次的功能变更粒度变得更小，可能前端改几个样式或者布局，不用担心会影响到后端的其他功能变更。后端子系统的变更，也不用担心把其它子系统未经过测试的功能一起发布出去了。这样，也就可以让大家更专注在自己的产品和系统，把精力更好的投入在子系统的优化和可用性等方面。
资源变更在k8s弹性云服务方面就更加简单了。弹性扩缩容变得非常容易，随时都可以按需申请服务器资源，不用担心资源紧张和资源浪费的情况。多地部署也变得极其简单，可以更进一步提高系统的可用性。
再多的技术栈，再复杂的服务依赖，都可以在 docker 中提前制作好，下载构建好的镜像就不再担心有遗漏了。在微服务平台提供的接口中心、权限中心，统一管理服务之间接口依赖，不再需要团队之间一对一的协调和联调，更加成熟的产品化和文档化。
业务和团队规模的变化，都不需要通过同事之间的口口相传，全部知识和依赖都在微服务平台上，只要把权限转移过去就可以了。

通过 devops 以及微服务平台，貌似解决了上面的所有问题，但也带来了一些新的问题。运维开发和平台带来了效率，也会把很多的工作和权限以及责任下放给了开发团队。微服务平台的能力非常多，意味着有大量的配置和操作。有些配置和操作在以前，都是由专业的运维团队来操作的，现在却要开发团队来处理，这也是一大难题。有些配置（如：健康监测、配置文件）如果出现问题，可能会导致集群和服务的不可用，这也是非常严重的风险。