脱离场景谈架构，都是耍流氓！ --出自：孙玄老师的名言(前58集团技术委员会主席)
其中SOA框架和微服务框架区别
一、概要
- 计划进行服务化改造的背景、前景
我们目前虽然也是按照不同维度来拆分多个不同的服务，来实现微服务，我们经常
会出现服务与服务之间调用卡壳，或者是其中一个服务出现问题，
那么依赖的服务直接被拖垮了，导致服务不可用。
基于以上问题（使用HTTPClient调用相关服务），我们引入SpringCloud 成熟的组件来应对以上的这些问题。
Spring Cloud 是 Java 领域最适合做微服务的框架。相比于其它框架，Spring Cloud
对微服务周边环境的支持力度最大。对于中小企业来讲，使用门槛较低。
Spring Cloud 是微服务架构的最佳落地方案。
处理服务发现的能力 – 服务发现允许集群中的进程和服务找到彼此并进行通信。
解决冗余问题 – 冗余问题经常发生在分布式系统中。
负载平衡 – 改进跨多个计算资源（例如计算机集群，网络链接，中央处理单元）的工作负载分布。
减少性能问题 – 减少因各种操作开销导致的性能问题。
- 当前系统开发、维护、排障遇到的困难/弊端/工时成本
目前系统开发过程中风格不统一，结构也有所不统一，这样一旦有人离职，接手别人手里
的代码，要从头开始找，如果出了问题，需要紧急修复，那必然要花费大量的时间是花在
找代码等问题上，可能改问题只需要短短的几分钟时间，如果说引入Cloud组件中链路追
踪，那么可以通过监控UI 来查看请求的链路(服务之间的调用、依赖关系等)
另外我们选择使用目前国内市场上比较主流的服务治理架构(dubbo)来作为每个微服务之间
通讯的组件，替代Spring Cloud 原生的Feign,因为Feign的底层协议是(HTTP),而dubbo
底层走的是TCP协议.
Dubbo Spring Cloud 完全地保留了原生 Spring Cloud 服务调用特性，不过
Dubbo 服务治理的能力是 Spring Cloud Open Feign
所不及的，如高性能、高可用以及负载均衡稳定性等方面。因此，建议开发人员将
Spring Cloud Open Feign 或者 @LoadBalanced RestTemplate 迁移为 Dubbo
服务。考虑到迁移过程并非一蹴而就，因此，Dubbo Spring Cloud 提供了方案，即
@DubboTransported 注解。该注解能够帮助服务消费端的 Spring Cloud Open Feign
接口以及 @LoadBalanced RestTemplate Bean 底层走 Dubbo 调用（可切换 Dubbo
支持的协议），而服务提供方则只需在原有 @RestController 类上追加 Dubbo @Servce 注解（需要抽取接口）即可，换言之，在不调整 Feign 接口以及 RestTemplate URL
的前提下，实现无缝迁移。如果迁移时间充分的话，建议使用 Dubbo
服务重构系统中的原生 Spring Cloud 服务的定义。
Spring Cloud Alibaba
参考duubbo官网
- 预期服务化改造完成后的优点
便于排查问题，能够快速锁定问题.
服务之间的调用更清晰，维护成本降低。
- CAP在微服务中的应用
在一个分布式系统中（指互相连接并共享数据的节点集合）中，当涉及到读写操作时，只能保证一致性（Consistence）、
可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。
在微服务的构建中，永远都逃离不了CAP理论，因为网络永远不稳定，硬件总会老化，软
件可能出现Bug，所以分区容错性在微服务中是躲不过的命题。
可以这么说，只要是分布式，只要是集群都面临着 AP 或者 CP
的选择，但你很贪心的时候，既要一致性又要可用性，那只能对一致性作出一点妥协，
也就是引入了 BASE 理论，在业务允许的情况下实现最终一致性。
究竟是选 AP 还是选 CP，真的在于对业务的了解，例如金钱，库存相关会优先考虑 CP
模型，例如社区发帖相关可以优先选择 AP
模型，这个说白了基于对业务的了解是一个选择和妥协的过程。
我们改造的目标是能够使我们每个微服务职责相对独立，服务的监控和维护更加清晰明了，服务之间的调用链路能够很直观的查看.并且引入服务的流控、熔断、降级，来保证服务的高可用.引入网关来实现服务的统一管理.(具体看针对Spring Cloud Gateway文章)
本次项目使用(Spring Cloud + Spring Cloud Alibaba)来实现服务改造(Spring Cloud Gateway + Nacos + Dubbo + Sentinel + Spring Cloud Sleuth)
本次改造计划，打算将日志存储在ES中，也为公司剩下一笔阿里的日志服务Money. O(∩_∩)O哈哈~
Other
二、实施计划
- 架构重构?
- 初期改造方向?
- 制定实施计划方案?