3分钟决策是否要用微服务架构

一.认识微服务架构

应用架构发展：单体应用  SOA(ESB) 微服务云原生

朴素理解转微服务架构就是系统服务化拆、再拆、再拆拆

微服务是一种架构风格不是技术标准。

微服务架构思想：

系统拆得小服务化

服务独立部署运行

服务间http/https轻量级通信（restful）

服务治理

服务开发可不限技术栈

服务可不同存储技术

可自研或Dubbo或spring cloud等

二.微服务解决什么问题

软件工程从来没有银弹。微服务架构也不是。

个人经验微服务架构解决下列问题之一：

业务复杂或将复杂难于扩展、维护

难于快速响应移动互联下多端产品需求差异多变化快

大流量高并发下很难保证高可用、稳定

三.微服务开发的工程性问题

技术选型 （spring cloud OR K8S OR K8S + istio）

业务如何拆分（没有标准）

建议子应用级别，不建议拆得太细，太细的话对服务治理挑战和代价更大。

技术规范制定

Restful API规范等开发规范、测试规范、运维规范。

开发、测试模式转变

前后端分离、小团队协同、DevOps开发模式

运维升级

容器化部署、配套服务治理基础设施搭建，如网关流控、全链路调用监控、日志采集与监控等

小结：

微服务架构开发是大而复杂工程，所有服务组件和服务治理的基础设施都要完善，才能走稳走远。

四.微服务架构的技术选型

从业务实际出发。看眼前收益也看未来。

Spring cloud +docker OR 云原生 K8S+istio：

组件Spring cloud云原生

自愈和自动伸缩无kube-controller-manager

调度和发布无kube-scheduler+Deployment

配置管理Spring Cloud ConfigConfigMap

服务发现与调用Eureka+Ribbon（Open Feign）Istio envoy

弹性和容错HystrixIstio envoy

网关ZuulIstio Gateway

服务安全Spring Cloud SecurityIstio Auth

调用链路监控Spring Cloud Sleuth+ZIPkinIstio envoy+Jaeger

Metrics监控actuator+Spring Boot AdminIstio+Prometheus

日志收集Spring Cloud Sleuth+ELKfuentd/Istio

比较：1）Spring cloud上手快、 K8S+istio复杂学习曲线高坑多点；

2）服务实现和服务治理前者耦合，应用侵入式 后者完全解耦，开发只关注业务效率更高；

3）前者只支持java，后者支持多语言；

个人经验建议：

团队人员具备K8S经验（或公司重视积极投入），优先云原生 K8S+istio。

因为随着5G和AI成熟、大数据云计算、万物智联发展趋势需要可以更快速灵活支持新业务的拓展。

java栈开发且历史包袱重建议spring cloud开发逐步演进。

---

文/老猿，写代码写诗写职场的程序猿大叔，倾力原创简单实用的硬干货，转载此文请联系老猿。