在开始之前呢，还是得废话一下，毕竟还是需要介绍一下这个系列我们要实现什么样的一套服务架构，也让大家能初步的有一个了解，后续实践起来也有一个完整的概念，相对也会容易的多。
互联网架构演变
随着市场的快速发展，业务的不断扩大，单块架构应用面临着越来越多的挑战，其改造与重构势在必行。而微服务架构的诞生，是互联网高速发展，虚拟化技术应用以及持续交付、DevOps深入人心的综合产物。随着用户需求个性化、产品生命周期变短，微服务架构是未来软件软件架构朝着灵活性、扩展性、伸缩性以及高可用性发展的必然方向。同时，以Docker为代表的容器虚拟化技术的盛行，将大大降低微服务实施的成本，为微服务落地以及大规模使用提供了坚实的基础和保障。
单体架构
记得刚毕业12年左右那会这种单体应用都是常规的一种软件开发设计模式，它足够简单,在当时能很好切较快的满足各种小心公司的各个业务模块。
优点
请求延时低
部署运维成本低
开发简单直接，集中式管理
单应用内基本不会重复开发
缺点
耦合严重，可拓展性差
技术选型单一
架构力度较粗，不能很好适应需求的迭代
提供服务困难，调用困难
配置越来越多管理也变得更加苦难
加载、编译缓慢
RPC架构
随着应用的迭代、系统访问量提高、业务复杂度提高、代码也越来越复杂，这个时候单体应用架构逐渐转变为面向服务的架构转变。RPC（Remote Promote Call） 一种进程间通信方式，允许像调用本地服务一样调用远程服务，在 .NET 语言，接触的比较少，在java当中如：spring cloud、dubbo。
优点
RPC框架一般使用长链接，不必每次通信都要3次握手，减少网络开销
RPC框架一般都有注册中心，有丰富的监控管理
发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作
协议私密，安全性较高
rpc 协议更简单内容更小，效率更高
服务化架构、服务化治理，RPC框架是一个强力的支撑
缺点
配置复杂
仅适用内部服务调用
多了一层间接性，出现网络问题时，debug比较困难
交互方式单一，不能进行复杂的多模块之间的协议交互
异常处理困难
改善了单体应用在系统间交互的不足，适用于内部服务交互。
微服务架构 与 SOA架构
这两个我就放一起说了，因为本质上SOA与微服务是一脉相承的，微服务相当于把SOA的理念继续升华，精进。
其核心思想是在应用开发领域，使用一系列微小服务来实现单个应用的方式途径，或者说微服务的目的是有效的拆分应用，实现敏捷开发和部署 ，可以是使用不同的编程语言编写。而SOA可能包含的意义更泛一些，更不准确一些。
随着业务发展，服务数量越来越多，服务生命周期管控和运行态的治理成为瓶颈，单体架构按照业务功能在垂直方向进行拆分，就变成了SOA架构，用于提升服务质量、服务治理。
微服务是一种架构风格，也是一种服务，通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成本也将大幅度下降。
优点
按业务边界拆分服务
服务可独立部署
服务复用率高
服务之间通讯也变得更加容易
从架构划分应用划分更加清晰
核心模块稳定，独立升级带来的影响较小
服务可根据分类到团队进行管理(维护、工作分明，职责清晰)
业务模块复用率相对较高
按照业务边界划分后的服务拓展也更加容易
可不同语言,引入新技术较为方便
微服务系列的实践方式
虽然微服务有着很大的优势，但同时我们面临的挑战也将更多：
服务多，配置管理复杂
服务间依赖关系复杂
服务需要通过负载集群实现高可用
服务调用关系及性能监控面临挑战
服务文档的规范
服务降级、熔断
服务的拓展性
我们的实现方式：
负载集群及高可用：keepalived + nginx
服务注册、发现、健康检查通知：consul
服务治理、性能监控、跟踪：skywalking
统一配置中心：apollo
集中的日志：elasticSearch + logstash + kibana
API网关(熔断、降级)：Ocelot
总结
总之呢，微服务的核心思想是有多个独立的微小的服务组成，每个服务的开发和发布都没有绝对的依赖关系。服务可独立拓展伸缩，每个服务应有自己明确的边界，也可以采用不同的编程语言来实现，我们主要做的就是给用户一个友好的体验，让用户能感受到它的方便简单和快捷，服务内部也应该有良好的日志和监控体系,提高服务的高可用、易拓展的能力。
原文地址: https://github.com/zengqinglei/microservice-deploy/wiki/01.%E5%BE%AE%E6%9C%8D%E5%8A%A1%E7%B3%BB%E5%88%97%E4%BB%8B%E7%BB%8D
扫一扫
753
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
