微服务架构的松耦合原则与遗留系统改造策略

微服务的发展源于两个问题：整体应用程序复杂化后耦合度太高、难以部署交付；面向服务架构（SOA）虽有异构连接和松耦合特性，但太复杂昂贵、难以理解实现，性价比不高。微服务架构把单个应用开发成一组小型服务，每个服务在自己的进程中运行、通过轻量级机制（通常是HTTP资源API）通信，服务围绕业务功能构建、可通过全自动部署机制独立部署，可以用不同编程语言编写、用不同数据存储技术，管理是集中式的——微服务把单块架构应用划分成一组互相协调配合的小服务，共同为用户提供最终价值。围绕微服务产品化，书中引用Uber SRE的Susan Fowler提出的八大原则（可用性、生产准备、稳定性、可伸缩性、容错和灾难预防、性能、监控、文档化），重点阐述其中两条。稳定性原则：微服务架构给了开发者很大自由度（每天增加发布新特性、修改Bug、重写或弃用过时服务），这正是解耦特性带来的优势，但如何在享受这种自由度的同时不影响整体可用性和正确操作才是关键——稳定标准要求：一个服务的开发、发布、新特性增加、Bug修复、停用、弃用，都不应该影响大的微服务生态系统的稳定性，只有做到这一点，系统才算真正利用了微服务的松耦合特色（而不只是表面上拆成了多个服务）。可伸缩性原则：微服务业务量很少恒定，不能扩展规模的微服务在业务量增大时会拉高延迟、降低可用性，极端情况甚至导致意外事故或停机——要确保可伸缩性，既要掌握定性增长规模（扩展的是页面浏览还是客户订单）也要掌握定量增长规模（每秒能处理多少请求），扩展规划要覆盖整个微服务系统（包括依赖的服务和数据存储都要能满足扩展需求），并要能应对突发流量而不至于整体垮掉。对已有紧耦合遗留系统做微服务化改造，书中给出一个真实案例的五步策略：最小修改（对现有系统禁止非紧急改动，用最小成本保障当前系统正常运行，同时把工作重心逐渐转向新服务改造）；功能剥离（在原系统外围逐步构建功能服务接口，把核心功能分离出来，用代理机制把用户对原系统的访问转发到新服务，从而解耦原系统与用户的直接依赖）；数据解耦（部分功能已能独立提供服务后，逐渐把相关业务数据从单块架构数据中剥离出来，让每个服务拥有独立隔离的数据系统）；数据同步（改造周期长、新服务短期内无法与原系统直接协作时，用ETL机制把新服务的业务数据同步回原单块数据库，保障原有功能能持续被使用，从而在改造过程中依然能持续交付价值）；独立服务（通过前述方式不断迭代，最终把功能连同业务逻辑和业务数据一起解耦成完全独立的服务）。