网站架构变迁( 二 )


当项目进行服务化改造的时候,这个过程并不是一蹴而就,一拍脑袋就成功了 。要把项目服务化,需要解决很多的问题,例如:
服务之间怎么调用?订单服务想要调用到商品服务的数据,怎么调用?怎么调用更加的稳定,更加高效?【服务调用技术】
服务之间怎么负载均衡?订单服务要调用商品服务,商品服务可能有很多个,怎么负载均衡【负载均衡技术】
服务怎么被管理?服务怎么定位?有故障了怎么处理?【服务注册与发现技术】
故障怎么监控?微服务系统中业务模块很多,组件也很多,不同组件的指标不同,那么这些组件怎么进行监控【监控技术】
故障怎么定位?微服务架构中,一个用户的请求会涉及到多个内部服务的调用,那么如何定位问题呢?【链路追踪技术】
日志怎么分析处理?业务模块多了,日志也就多了,直接查看日志文件已经变的不显示了,那么如何对日志进行分析查找呢?【日志分析技术】
权限管理?微服务拆分服务之后,会有很多服务对外暴露接口,这些接口如何进行统一的权限处理呢?【网关技术】
服务调用出现问题怎么处理?当一个服务因为各种原因停止响应时,调用方通常会等待一段时间,然后超时或者收到错误返回 。如果调用链路比较长,可能会导致请求堆积,整条链路占用大量资源一直在等待下游响应 。怎么解决呢?【服务熔断,降级,限流】

网站架构变迁

文章插图
 

网站架构变迁

文章插图
 

网站架构变迁

文章插图
 
微服务架构 2.0基于 Kubernetes + ServiceMesh 的云原生微服务架构
微服务 2.0 更多的注重服务的治理,2.0 阶段,微服务架构引入了 ServiceMesh(服务网格)的概念通过 SideCar(侧边车)的方式实现一些对应用无侵入的管理,使得服务治理更加通用,借助 Service Mesh 可以更方便的管理服务间调用,更好的做流量控制等
追本溯源,服务网格从无到有可分为三个演化阶段(参见下图) 。第一个阶段,每个服务各显神通,自行处理对外通讯 。第二个阶段,所有服务使用统一的类库进行通讯 。第三个阶段,服务不再关心通讯细节,统统交给边车进程,就像在TCP/IP协议中,应用层只需把要传输的内容告诉TCP层,由TCP层负责将所有内容原封不动的送达目的端,整个过程中应用层并不需要关心实际传输过程中的任何细节 。
网站架构变迁

文章插图
 

网站架构变迁

文章插图
 

网站架构变迁

文章插图
 
Kubernetes 让微服务更简单,使用 Kubernetes 就无需关注服务的注册发现了,服务部署自动服务注册发现,无需在应用代码里向服务中心注册,kubernetes 让微服务的缩放更为简单,你也可以配置根据应用的 CPU 等指数来实现应用的动态扩容,压力大的时候自动扩容,增加节点,压力小的时候自动缩放,减少服务节点 。
网站架构变迁

文章插图
 

网站架构变迁

文章插图
 
More一切脱离业务的架构设计,都是耍流氓 。
架构不是一蹴而就的,架构是演化出来的 。
笔者经验有限,文中如果有错误,还望指出,万分感谢
Reference
  • https://www.zhihu.com/question/37808426
  • https://www.zhihu.com/question/65502802
  • https://juejin.im/entry/5bd6846ee51d452f7110cfeb
  • https://zhuanlan.zhihu.com/p/35179248
  • https://www.infoq.cn/article/microservices-post-kubernetes
作者:WeihanLi




推荐阅读