微服务诞生背景
微服务架构的概念和发展可以追溯到2014年，当时由Martin Fowler和James Lewis共同提出了这一概念。不过， 微服务架构的思想并非一夜之间形成的，它是在软件开发领域长期演进的结果。
在微服务出现之前，传统的软件架构通常是单体应用，即整个应用作为一个单一的单元进行构建、部署和扩展。 单体应用在初期易于开发和部署，但随着业务的增长和技术的发展，这种架构开始暴露出一些问题，比如难以扩展、不易维护、对新技术的采纳缓慢等。 随着互联网业务的爆发式增长，特别是移动互联网的兴起，单体应用难以应对高并发访问和快速迭代的需求，所以微服务架构应运而生， 它将应用程序分解成一组小型、独立的服务，每个服务 都围绕着特性的业务功能进行构建，并且能够独立的部署、扩展和维护。
(来自：blog.bytebytego.com)
微服务治理技术发展趋势
笔者在微服务架构下经历过以下两个阶段：
第一个阶段:
• 微服务框架：主要针对大规模高并发场景，通过去中心网关、 做厚客户端的方式，使得企业内部应用可快速解耦和横向扩容，以满足业务快速发展需求 。该阶段，服务治理功能一般通过 SDK，部署在业务程序上，辅以注册中心和配置中心进行服务管理。 这个时期主要代表的是SpringCloud和Dubbo。 虽然性能和可靠性得到解决，但是服务治理逻辑和业务逻辑存在一定程度耦合， 在应用生命周期迭代上存在一定问题。
第二个阶段:
• 云原生 Service Mesh：将更多的服务治理能力沉淀到云平台上，应用只关注业务逻辑， 服务治理和应用彻底解耦，应用快速迭代得到解放。该阶段，服务治理功能以代理边车方式沉淀到容器内， 应用时在运行时挂载边车即可，具体的服务治理控制逻辑由云平台(如图中 Kubernetes/Service Mesh)承接。 但是Service Mesh中的Sidecar代理模式会引入额外的数据传输延迟，因为每个服务请求都需要经过代理进行转发 ，网络上会有一定延迟影响。每个Sidecar会单独占用cpu与内存增加整体资源的开销。
那么有没有一种方案，既能具备Sidecar代理模式的各种解耦优点，又能一定程度上克服 Sidecar代理带来的问题呢？答案是 JavaAgent。
JavaAgent优势：
• 相比传统Sidecar代理架构，没有额外进程，性能更好，资源消耗更低，以及额外的进行资源开销。由于JavaAgent这块采用和SDK雷同的AOP服务治理方式，所以性能几乎与SDK持平。
• JavaAgent相比SDK升级动辄需要取各业务方推广，耗时长、历史包袱重等问题，非侵入这块能力比SDK实际体验好太多，治理功能快速迭代时，业务方只需要滚动重启一下就可以获得新的治理能力，这对服务治理团队和业务团队都是一种生产力解放。
flowsphere开源项目
flowsphere是基于bytebuddy字节码增强技术进行建设，采用插件化方式进行整体架构设计， 利用字节码增强技术为微服务提供全链路流量治理能力。全方位扩展SpringCloud&SpringCloudAlibaba， 扩展Java生态提供高性能，低资源损耗，降本增效的流量治理框架。
全局架构图
全链路泳道全景图
微服务控制台
主要特性
1.支持基于标签路由全链路灰度发布，支持Http、MQ、JOB多种标签过滤方式
2.支持基于用户、区域维度标签权重负载均衡路由
3.支持无侵入式接入Sentinel框架，轻松拥有限流、故障隔离等能力
4.采用字节码增强技术，对业务代码无侵入，业务性能影响最小；
5.采用微内核架构，强类隔离，简单易用的扩展和配置体系。
基本能力
支持阿里巴巴Nacos、Eureka、Consul和Zookeeper四个服务注册发现中心
支持阿里巴巴Nacos、携程Apollo两个远程配置中心
支持阿里巴巴Sentinel熔断限流降级中间件
支持Java Agent解决异步跨线程ThreadLocal上下文传递
支持Spring Cloud Gateway、Zuul网关和微服务三大模块的灰度发布和路由等一系列功能
欢迎使用flowsphere
目前flowsphere正在快速发展，如果您对以上细节感兴趣，欢迎访问github.com/flowsphere-… 项目地址start一波。
