微服务漫谈
【空山新雨】 人气:2微服务可以说是近几年技术圈异常火爆的概念，人人都在说微服务，人人都在致力于打造自己的“微服务”。甚至于某些压根不懂技术的项目招标方都在问你们公司用了微服务吗？“微服务”俨然成了衡量团队技术实力或技术逼格的代名词。
但是，微服务真是万能的吗？是不是来个项目就得微服务一下，不然就显得落伍，显得low了呢？本文一起聊聊“微服务”的那些事。
一. 什么是微服务？
微服务是一种架构风格，由Martin Fowler（牛人，ThoughtWorks公司的首席科学家，同时也是敏捷开发方法的创始人之一）提出，是指将复杂应用通过拆分为一系列高内聚、低耦合、自治的小（微）服务，每个服务独立开发（可以使用不同的编程语言），独立部署（运行在不同的进程中），并通过轻量级的通信机制（Restful API）进行交互。微服务本质上还是SOA（Service-Oriented-Architecture, 面向服务的架构），但微服务不限定于特定的技术，通过Restful架构风格来完成系统的统一，因此比传统的SOA（一般基于较重的SOAP、WSDL、UDDI等协议技术，通过企业服务总线ESB进行连接集成）更为灵活，更具扩展性。
微服务的特征：
1. 是一种应用于组件设计(服务如何拆分)和部署架构(服务如何部署和通信)的模式
2. 适用于创建具有“一定功能复杂性”的分布式应用系统
3. 各个服务必须小，只负责某个具体的业务功能，比如商品服务，订单服务，根据功能实现关注点分离
4. 各个服务保持自治和相互解耦，进行独立开发、独立部署，及独立升级与伸缩
5. 各个服务之间通过轻量级 API （Restful API）和异步通信（如消息队列）相结合的方式进行通信
二. 微服务的优缺点
微服务的优缺点一般相对单体应用（就是所有功能、代码都整在一个工程项目中）而言
1. 微服务的优点：
1.1 简化复杂的业务模型
微服务将复杂的业务通过一系列的高内聚、低耦合的小型服务来实现，体现了分治的思想。每个服务的开发与维护都非常高效，可管理性更高，能快速响应需求。
1.2 不局限于某项特定的技术
因为服务间是通过轻量级的Restful API交互，每一个服务可以独立开发，可选用不同的编程语言与技术框架（虽然实际中对于一般规模一般都是统一的）。
1.3 独立部署与升级，按需伸缩
每个服务都是独立部署，运行在不同的进程中，因为加载内容相对较少，所以一般启动也比较快。单个服务的升级对系统整体的影响也较小。同时可以针对各个服务的负载情况，进行独立的按需伸缩。
2. 微服务的缺点：
2.1 对“微”的粒度与服务的边界难以把握
微服务开发过程中，开发人员最常见的疑问就是这个接口应该放到哪个服务里。服务应该微到什么程度，服务边界与服务交互如何定义与规范，需要有对业务、技术充分了解的专业人员做上层设计（一般就是架构师），并且持续跟进实施落地，否则很有可能就会导致只是将一个单体应用拆成了多个单体应用，或编织了一张交互错综复杂的服务网络的尴尬局面。
2.2 引入了分布式的复杂性
微服务中某一个请求可能就涉及好几个服务间的调用，如果出现问题，则定位相对困难复杂；同时基于CAP（Consistency，Availability， Partition Tolerance）理论，分布式系统中一致性、可用性、分区容忍性只能同时满足两个，一般在满足可用性与分区容忍性的基础上，对系统提供最终一致性保障。
2.3 对技术栈的要求更高
团队需要对微服务基本理论与相关技术有一定了解，且需要搭建许多业务服务之外的基础设施服务，比如服务注册发现、配置管理、链路监控等。目前微服务技术最热的就是Spring Cloud，也有部分团队选择Dubbo。
2.4 对运维的要求更高
微服务将一个复杂应用拆分为几十个甚至上百个小型服务，迭代升级部署的频率比单体应用更高，采用传统的运维手段很难满足需求，一般需引进DevOps的相关技术手段，如CI（持续集成）、CD（持续部署）、自动化测试、容器化与服务编排，及丰富的监控告警机制等。
三. 如何抉择？
如之前文章说到的，技术人员的能力在于解决问题的能力（当然解决问题也分临时性的解决问题与前瞻性的解决问题——解决方案能在较长一段时间内适用）。技术管理者或技术决策者最基本的修为就是在过火过热的各种技术概念与技术框架面前保持冷静，选择最适合业务场景与自身团队的技术方案。
要不要用微服务，什么时候不该用微服务？结合自身理解，总结整理如下：
1. 业务简单，应用规模很小不该用微服务
杀鸡不能用牛刀，微服务旨在将复杂业务拆分，简化业务规模， 如果业务本身很简单，一个单体应用就能处理的场景不该用微服务。
2. 业务领域不够清晰、明确不该用微服务
业务领域不清晰、不明确，意味着整个业务定义、业务框架都可能朝令夕改，如果采用微服务，则可能导致牵一发而动全身的痛苦局面。
3. 团队技术储备不够不该硬上微服务
微服务的分布式特性对团队的技术要求比单体应用高， 如果团队大部分成员之前都没接触过微服务，对微服务缺乏基本的了解，不该硬上微服务。
4. 小型创业公司不适合用微服务
该条其实是前面几条的汇总，因为小型创业公司一般就意味着业务相对简单，并且业务领域、设计不够清晰、明确，以及团队技术实力相对较弱，并且人员流动性大等特点，任何一点都不利于微服务的构建。
对于业务较为明确且复杂的系统，如果你团队的技术储备达到一定水平（如对Spring Boot，Spring Cloud，CI/CD，Docker/K8s等有一定掌握），并且有一个对业务与技术都有充分了解且具备决策权的master，微服务无疑是一个很好的选择。否则，慎重！
四. 总结
任何技术与框架都有其适用场景，微服务不是万能钥匙。应结合具体的业务场景，团队组成，技术储备等因素综合考虑，选择最适合自身的技术方案。
欢迎关注我的微信公众号：jboost-ksxy
加载全部内容