架构演进
-
单体应用
- 实际上没什么架构的概念，所有的业务逻辑都在一个项目里打包成一个二进制的编译后文件，通过这个文件进行部署，并提供业务能力。它就像夫妻店，很小很灵活。但是处理能力有限；没有分工，难以扩展。
-
分层结构（mvc）
- 又叫“三明治”架构。分层架构中的每一层都着特定的职能。层之间是隔离的，即一个请求，必须一层一层的传递，而不能跨层传递。分层架构的流行，催生了大量的可复用的中间件。它就像一个工作室，有了明确分工的几个组，团队的能力大于个人，处理能力有了一定的提升。但是面对更复杂服务要求的时候，无论是扩展能力，还是服务能力，都有点力不从心。
-
SOA
- 即面向服务的架构（Service Oriented Architecture），它的关注点是服务。一个服务定义了一个相对独立、自包含、可重用的业务功能。服务间一般通过企业服务总线（ESB）的方式组装起来。它就像公司一样，可以把各个较独立的服务组装起来，对外提供更复杂的服务，满足客户更多样化的需求。SOA架构要提高扩展性，就需要采用“分布式”的方式了。那么，各种服务如何行“分布式化”？这就催生了下面要说的微服务架构。也可以认为，微服务架构就是SOA架构分布式化的一种实现。
-
微服务
- 以一组小而自治的服务来构建整个系统，系统的一大特点是去中心化，从而实现更灵活的扩展能力。它就像集团一样，每个服务都独立而自治，整个系统（集团）具有很强的弹性，扩展自如，风险可控。当然，这样的弹性是要付出一定代价的。
网络截图，侵权可删
微服务的特点
- 服务拆分力度更细
- 服务独立部署
- 服务独立维护
- 服务治理能力要求高
微服务的拆分
- 垂直拆分
- 从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。
- 水平拆分
- 从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。
微服务框架
- springcloud（主流，Pivotal java）
- motan（微博 java）
- Tars（腾讯 c++）
- double+zk（阿里 java）
- springcloud（阿里组件）
- gRPC（谷歌 跨平台）
- Thrift（facebook，apache 跨平台）
微服务依赖组件
- 服务描述（服务如何对外提供功能，例 swagger、 xml、IDL）
- 注册中心（服务订阅和发布，例 consul）
- 服务框架（通讯协议、数据传输方式、数据传输格式）
- 服务监控（指标收集、数据处理、数据展）
- 服务追踪（链路追踪、性能优化 例 twitter zipkin、阿里鹰眼、美团 MTrace）
- 服务治理（节点管理、负载均衡、服务路由、服务容错）
微服务springcloud详解
- Eureka 注册中心
- feign 服务调用
- Zuul 、gateway 服务网关
- Hystrix 熔断器
- config （apollo协程） 配置中心
- Bus 服务总线
- Sleuth 链路追踪
- Turbine 熔断监控
- springboot admin 监控jar
- 阿里自己的组件 nacos sentinel
- ELK 聚合日志
image.png
微服务部署
- docker
- jenkins、gitlab-ci
- k8s
- Devops
- CI/CD
- Servicemesh
