-
自动化部署：
微服务架构，节点数动辄上百上千，自动化部署能够提高部署速度和部署频率，从而保证持续交付。
包括版本管理、资源管理、部署操作、回滚操作等功能。
而对于微服务的部署方式，包括蓝绿部署、滚动部署以及金丝雀部署。
-
配置中心: 运行时配置管理能够解决动态修改配置并批量生效的问题。
包括配置版本管理、配置项管理、节点管理、配置同步等。
-
持续交付：
包括持续集成、自动化部署等流程。
目的就是小步迭代，快速交付。
- 进一步提升运维效率
-
服务监控: 微服务架构下节点数目众多，需要监控的机器、网络、进程、接口等的数量大大增加，需要一个强大的监控系统，能够提供实时搜集信息进行分析以及实时分析之上的预警。
包括监控服务的请求次数、响应时间分布、最大/最小响应值、错误码分布等
-
服务跟踪：
跟踪一个请求的完整路径，包括请求发起时间、响应时间、响应码、请求参数、返回结果等信息，也叫做全链路跟踪。
通常的服务监控可以和服务监控做在一起，宏观信息由服务跟踪呈现，微观单个服务/节点的信息由服务监控呈现。
服务跟踪目前的实现理论基本都是Google的Dapper论文。
-
服务安全：
内网之间的微服务调用原则上讲应该是都可以互相访问写，一般并不需要权限控制，但有时候限于业务要求，会对接口、数据等方面有安全控制的要求。
此部分可以以配置的方式存在于服务注册中心中，和服务绑定，在请求时由做为服务提供者的服务节点进行安全策略控制。
配置则可以存储在配置中心以方便动态修改。
在微服务数量很少的情况下，以上基础设施的优先级自上而下降低。否则，仅仅依赖人工操作，则投入产出比会很低。
还需要提到的是Docker容器技术。虽然这个对于微服务并不是必须的，但是容器技术轻量级、灵活、与应用依存、屏蔽环境差异的特性对于持续交付的实现是至关重要的，即使对于传统的单体应用也能够给其带来交付效率的大幅提升。
架构设计模式
在引入微服务之后，传统的单体应用变为了一个一个服务，之前一个应用直接提供接口给客户端访问的架构不再适用。微服务架构下，针对不同设备的接口做为BFF层（Backend For Frontend），也叫做用户体验适配层，负责聚合、编排微服务的数据转换成前端需要的数据。服务之间的调用则在允许的情况下（允许延迟）尽可能使用异步消息传递方式，如此形成面向用户体验的微服务架构设计模式。如下图所示：
Client -> API Gateway -> BFF（Backend For Frontend） -> Downstream Microservices
-
后台采用微服务架构，微服务可以采用不同的编程语言和不同的存储机制。
-
前台采用BFF模式对不同的用户体验（如桌面浏览器，Native App，平板响应式Web）进行适配。
-
BFF、API Orchestration Layer，Edge Service Layer，Device Wrapper Layer是相同的概念。
-
BFF不能过多，过多会造成代码逻辑重复冗余。
-
可以将网关承担的功能，如Geoip、限流、安全认证等跨横切面功能和BFF做在同一层，虽然增加了BFF层的复杂性，但能够得到性能优势。
服务拆分
微服务架构最核心的环节，主要是对服务的横向拆分。服务拆分就是讲一个完整的业务系统解耦为服务，服务需要职责单一，之间没有耦合关系，能够独立开发和维护。
服务拆分不是一蹴而就的，需要在开发过程中不断地理清边界。在完全理清服务之前，尽量推迟对服务的拆分，尤其是对数据库的拆分。
拆分方法如下：
-
基于业务逻辑拆分
-
基于可扩展拆分
-
基于可靠性拆分
-
基于性能拆分
其中，对于无法修改的遗留系统，采用绞杀者模式：在遗留系统外面增加新的功能做成微服务方式，而不是直接修改原有系统，逐步的实现对老系统替换。
拆分过程需要遵守的规范如下：
-
先少后多、先粗后细（粒度）
-
服务纵向拆分最多三层，两次调用：
Controller、组合服务、基础服务
-
仅仅单向调用，禁止循环调用
-
串行调用改为并行调用或者异步化
-
接口应该幂等
-
接口数据定义严禁内嵌，透传
-
规范化工程名
-
先拆分服务，等服务粒度确定后再拆分数据库。
微服务框架
上面讲述了微服务架构的众多基础设施，如果每一个基础设施都需要自己开发的话是非常巨大的开发工作。目前市面上已经有不少开源的微服务框架可以选择。
-
Spring Boot
Spring Boot是用来简化新Spring应用的初始搭建以及开发过程的。其虽然不是微服务框架，但其设计的初衷本质就是微应用的底层框架，因此非常适合用于微服务基础设施的开发以及微服务的应用开发。尤其对于Spring技术栈的团队来说，基于Spring Boot开发微服务框架和应用是自然而然的一个选择。
-
Dubbo&&Motan
Dubbo阿里开源的服务治理框架。其出现在微服务理念兴起之前，可以看做是SOA框架的集大成之作。但其仅仅包含了微服务基础设施的部分功能，诸如熔断、服务跟踪、网关等都没有实现。
Motan则是微博开源的类似Dubbo的RPC框架，与Dubbo相比更轻量级。
-
服务发现 ：
服务发布、订阅、通知
-
高可用策略 ：
失败重试（Failover）、快速失败（Failfast）、资源隔离 - 负载均衡 ：
最少活跃连接、一致性 Hash、随机请求、轮询等
-
扩展性 ：
支持 SPI 扩展（service provider interface）
-
其他 ：
调用统计、访问日志等
-
Spring Cloud
Spring Cloud是基于Spring Boot实现的微服务框架，也可以看做一套微服务实现规范。基本涵盖了微服务基础设施的方方面面，包括配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等。其基于Spring生态，社区支持非常好。但其很多组件都没有经过生产环境验证，需要慎重选择。
Spring Cloud Netflix是Spring Cloud的一个子项目，是Spring对Netflix OSS的集成实现。基于Netflix的大规模使用，其中的已经被广泛使用的组件包括：
此外，另一个子项目Spring Cloud Alibaba则是Alibaba开源的基于Spring Boot的微服务框架，主要是对阿里云服务的支持。
-
Eureka：
服务注册和服务发现
-
Ribbon：
弹性而智能的进程间和服务通讯机制，客户端负载均衡
-
Hystrix：
熔断器，在运行时提供延迟和容错的隔离
-
Zuul: 服务网关
-
Service Mesh
上述的微服务框架都是侵入式的，服务化的过程都需要进行代码改造。Service Mesh则是下一代微服务架构，最明显的特征就是无入侵。采用sidecar模式来解决系统架构微服务化后的服务间通信和治理问题。如下图所示：
目前主流的开源实现包括：
限于Service Mesh带来的性能延迟的开销以及sidecar对分布复杂性的增加，其对大规模部署(微服务数目多)、异构复杂(交互协议/开发语言类型多)的微服务架构带来的收益会更大。
-
Linkerd和Envoy：
以 sidecar 为核心，关注如何做好proxy，并完成一些通用控制平面的功能。
缺乏对这些sidecar的管理和控制。
-
Istio和Conduit：
目前最为流行的Service Mesh实现方案，集中在更加强大的控制平面(sidecar被称为数据平面)功能。
前者由Google和IBM合作，并使用了Envoy作为sidecar部分的实现；
后者则是Linkerd作者的作品。
相比起来，Istio有巨头背景，功能强大，但可用性和易用性一直不高，Conduit则相对简单、功能聚焦。
- Sofastack
蚂蚁金服开源的构建金融级分布式架构的一套中间件。包括微服务开发框架、RPC框架、服务注册中心、全链路追踪、服务监控、Service Mesh等一整套分布式应用开发工具。
特别值得一提的是SOFAMesh。其是对下一代微服务架构Service Mesh的大规模落地方案实践，基于 Istio改进和扩展而来，应该是国内最为成熟的开源Service Mesh方案。
此外，需要提到Kubernetes(K8s)，其本身提供了部分的微服务特性支持（通过域名做服务发现），对代码无侵入。但服务调用、熔断这些都需要自己实现。
综上，目前公司技术团队技术栈是Spring，并且已有服务的实现都是基于Dubbo，因此选择Spring Cloud Netflix做为基础的微服务框架，对其中不成熟或者缺乏的组件，选择业界更为成熟的组件替代即可。
-
API网关：
Zuul
-
服务注册中心：
Dubbo
-
配置中心：
disconf
-
服务监控&&全链路追踪：
CAT
-
服务开发框架：
Spring Boot
件，选择业界更为成熟的组件替代即可。
[外链图片转存中…(img-p6btx34o-1631194473575)]
-
API网关：
Zuul
-
服务注册中心：
Dubbo
-
配置中心：
disconf
-
服务监控&&全链路追踪：
CAT
-
服务开发框架：
Spring Boot