传统软件架构 PK 微服务架构

梦想与现实

贫穷的我们天真的以为学一个技术，可以吃一辈子的饭。但处于猪都能飞的互联 时代，才发现吃三五年就不错了。理想没有能照进现实、所以同志还需努力。技术的发展已经改变了我们构建应用程序体系结构的方式。虚拟主机、云服务和容器编排服务（如K8S、Swarm、Openshift）为我们带来了开发分布式、可伸缩和可靠解决方案的能力。今天就和大家说一下传统架构和微服务的大PK。这决定着我们运维工程 师、运维开发工程师、DevOps工程师的主要发展方向 。

微服务和传统架构对比

从两个架构来对比，可以发现好像微服务架构维护的服务器、及结构好像比传统架构更复杂了。对人员的工作技能要求反而更多了。那为什么还要用微服务架构，请继续往下看。

微服务和传统架构部署

1. 如果Jenkins校验和人工校验均通过情况下，代码被合并到目标分支。
2. 代码版本控制服务器会触发一个事件给Jenkins，Jenkins针自动的完成构建、单元测试、集成测试、部署等一系列的部署。

传统架构/微服务的选择

1. 微服务由于把单一软件拆分成更小的模块、所以在部署频率、服务器数量方面、及各个模块间的通信、服务治理等各方面较比传统架构更复杂和难以管理。
2. 但往往事情都有两面性、由于微服务是被单一软件拆分成更小的模块，所以构建部署方面也更快。以前传统架构、某一服务有问题可能需要修改整个架构、而微服务把问题最小化。各个之间互不影响。
3. 在软件回滚方面更加灵活、微服务在比如常用的蓝绿部署、回滚更新、金丝雀发布等方面更灵活。