一.认识微服务架构
应用架构发展：单体应用 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开发逐步演进。
文/老猿，写代码写诗写职场的程序猿大叔，倾力原创简单实用的硬干货，转载此文请联系老猿。
