服务简史历史总是惊人的相似。我们经历过“合”：单体架构（软）、超算力小型机（硬）到“分”：分布式架构的改造，后期可能把“分”发挥到极致（去中心化分布式，比如区块链），最后很可能会经历“结合”：具有超强计算和存储能力的“智人”（边缘计算的升级，超算和存储融合的人工智能）。为什么单体架构要进化？笔者认为，主要体现在以下三点：一是业务量在增加。互联网的发展对应用开发提出了更高的要求。随着业务量级和效率的提升，传统单体架构将成为瓶颈。2.可以收集的信息越来越多。互联网的快速发展也促进了云计算、大数据、人工智能的快速落地。数据采集??跨越软硬件，数据本身的价值也得到提升。使用微服务架构正好解决了大部分痛点。3、万物互联对数据连接的要求：系统之间、系统与硬件之间的数据连接必须保证高性能、高安全、高标准。我们实现了微服务架构：技术架构受公司业务和组织架构的影响。作为一个单体架构出身的人，一开始我是拒绝的，或者是担心拆分后我们的业务不稳定。但随着业务的突然扩张和业务的不断细分，敏捷开发和配套的技术解决方案迫在眉睫。毕竟，我们必须迈出这第一步。2015年下半年，我们走上了微服务的不归路。技术选型首先，根据整体业务规划，我们先做了初步的技术架构方案，然后确定了选型思路：不绑定具体的框架，最好的跨语言服务是Restful风格（极简风格，和是主流标准）足够简单，易于实现，未来可以扩展，稳定性强，与Docker（自动化运维）兼容性好。有了一个想法，按照我们的方法论，需要根据现有的主流架构进行对比筛选，然后再敲定：Dubbo、DubboX：优势在于全栈和强大的服务治理支持。它们是阿里巴巴的开源产品，已经被阿里巴巴实践过。中文文档多，社区活跃。但选型时停止维护，难以跨语言。SpringCloud：是Spring的一个子项目。社区足够强大，架构本身简单方便，几乎零配置。基于RESTfulAPI，跨语言。但是那个时候SpringCloud的实践很少，性能也不比RPC优越。Motan：是微博平台的微服务框架，承载了微博平台千亿级的业务调用。优势在于性能，实现了模块化、结构简单、易用性、跨语言，但对复杂业务的支持还不够好Thrift、gRPC：不能算是微服务框架，不包括必要的功能，例如服务发现。Istio:ServiceMesh思想可以看作是微服务架构的升级。类似于serverless要解决的问题。它将业务/算法与服务治理分开。当时技术还不成熟（这个是后来选型的时候加的），受限于当时的技术。由于团队的资源限制，我们按照阻力最小的原则选择了SpringCloud。springcloud提供了一些开发分布式服务系统的常用组件，如服务注册与发现、配置中心、熔断器、智能路由、微代理、控制总线、全局锁、分布式会话等。如下图所示：架构更换的短期探索和调试，我们准备开始试水。主流业务我们暂时不敢碰。我们会从一些接口服务和一些对外提供的独立系统入手。我们在这个阶段尝到了甜头，但之后，各种填坑，质疑声不断，但最终我们还是坚持了下来。最初转型构建容器云支持微服务后，给我们带来了一些额外的烦恼：微服务过多，服务治理成本高，不利于系统维护。分布式系统开发的技术成本高（容错、分布式事务等），对团队提出了很大的挑战。显然，我们无法通过启动jar包来维护大量的微服务，而且这些服务部署在一起，相互影响。什么是完整的？容器云+微服务我们引入微服务后不久，并没有急于替换所有业务，而是做好了基础运维，然后引入了Docker。Docker为我们带来：迭代效率提升支持：Docker用户发布软件的平均速度提高7倍虚拟机可以运行几十个容器标准统一：可以实现环境甚至架构的复制。仅靠Docker是不够的。我们发现引入Docker容器后，虽然解决了一些问题，但还不够。各种Docker命令和脚本，我们运维起来太麻烦了，我们甚至不知道自己有多少个服务，它们的健康状态，资源使用情况。当业务量激增时，我们是否总是被动地、手动地进行？服务是否可扩展？然后我们引入了一个容器编排工具：Rancher，围绕Rancher+Docker构建了一套容器云和一套DevOps工具（本文不重点介绍，欢迎关注后续文章）。当我们从大量的运维工作中解放出来后，发现小团队也可以做大事：小团队运营，敏捷的开发方式，其他业务解决方案的打包，一键部署，解放人力来构建我们的同样重要的DPaaS平台一些业务变化模块的快速优化甚至重构已经初见成效。虽然说微服务架构替换现有业务说起来容易，但整个替换过程持续了将近2年。到2017年底，我们已经形成了一套基于容器的云和微服务架构体系的解决方案，整体架构如下图所示：
