微服务架构体系发展

微服务架构体系

前段内部听了下分享 Service Mesh。做一些总结

架构的演进

这种东西有点信雅达，没什么绝对标准

• 单体应用：在第一阶段的单体应用很好理解。
• 垂直应用：接着随着业务量增大, 将应用拆成互不相干的几个应用，Web框架(MVC) 是关键。
  • 这一步，前后端分离、使用缓存、数据库和应用服务分离都会做, 但服务间是独立的无法调用，且可能存在重复代码。
• 分布式应用：垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务。这时用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
  • 集群、读写分离、反向代理、加速、分布式数据库、nosql、服务拆分都会处理、消息。
  • 实现了服务调用，代码复用

其实这时已经能算一种“微服务”了，一般会使用SpringBoot

• 弹性流动计算：服务越来越多，容量评估，资源的使用等问题逐渐显现，需要调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的 资源调度和治理中心(SOA 面向服务架构) 是关键。
  • 这时候要有一个注册中心，调用关系不需要自行维护了。
  • Dubbo 就是SOA的概念了，更关注RPC和服务治理。
• 微服务：最后是通俗含义的微服务，使用 SpringCloud编码，使用Docker、K8S等，解决微服务软运维问题。
  • 微服务本身也算是面向服务架构（SOA），它是SOA发展道路上的优化选择，关注的是服务拆分力度，即：如何将服务合理的拆的更细、更小
  • 微服务需要关注点又更多，监控、日志、安全、调度、弹性容错等

微服务和SOA

1. 微服务相比于SOA更加精细，微服务更多的以独立的进程的方式存在，互相之间并无影响，不再需要协调其它服务部署对本服务的影响；
2. 微服务提供的接口方式更加通用化，如HTTP RESTful，各种终端都可以调用，无关语言、平台，所以技术可以更随意，只需要提供API
3. 微服务更倾向于分布式去中心化的部署方式，数据的去中心化，也可以使用更不同的数据库技术；
4. 微服务运维使用docker,k8s 可以自动化部署，集中管理。

   	SOA	微服务
   服务粒度	粒度较粗	细粒度拆分
   部署难度	需要重新创建或者部署整个应用	每个微服务可以独立构建部署
   通信开销	大部分业务模块在一个应用里面，通信开销低	更多的远程调用，增加了通信开销
   存储	一般所有服务共享数据存储	每个可以拥有单独的存储
   业务易上手	需要了解整个应用的业务，上手较难	单服务上手容易，但是服务集群理解比较难(复杂度守恒定律：业务复杂度不会因为迁移到了微服务而降低)
   通信方式	SOA体系结构依赖于消息传递（AMQP，MSMQ）和SOAP作为主要的远程访问协议，协议偏重量级；	使用轻量级协议，如HTTP/REST
   可扩展性	难以扩展	使用容器技术很方便扩展

微服务和分布式

分布式关注的是服务分开部署，也就是如何将单一服务部署，变为多服务部署（垂直+水平拆分）。
微服务关注的是服务拆分力度，即：一个服务要拆分到多大的维度合适

Spring Cloud 和 Dubbo

说到微服务，两大框架的讨论肯定跑不了

区别