微服务架构入门

一、SOA思想

创建一个工程部署在服务器上，服务器中有许多方法，并且为这些方法提供接口去给别的应用比如APP、WEB等调用，调用方式可以是http链接，或者是基于socket的RPC调用。就是说把这个操作封装到一个工程中去，然后暴露访问的方式，形成服务。这个方法解决了在多个端都需要写同一段代码的问题，体现了封装的思想。

1.1 SOA的好处

1.1.1 拓展方便

当某个功能因为被频繁调用而使服务器压力过大时，可以将这个功能单独集群部署到新的服务器，缓解服务器压力。
集群和分布式的区别：集群是两个单位做一样的事情，比如两个厨师。分布式是两个人做不一样的事情，比如厨师和备菜小弟。

1.1.2 语言通用

实现这个服务的可以是任何语音，只要提供的接口通用就可以了，比如PHP擅长处理逻辑、Ruby语言擅长高并发、java擅长大数据等那我可以再比如某些业务逻辑很复杂的服务中使用PHP，在某些并发很高的服务中使用Ruby。

1.1.3 新人友好

新人进公司的时候他无需了解整个项目的架构是怎样的，比如你进阿里了，你想要熟练整个淘宝的架构你会累死，而这种SOA思想开发的项目由于是服务形式的，比方把你分到购物车组，那你只需要了解购物车的功能就好了。

1.1.4 发版方便

比方说你是淘宝购物车项目组的，你的项目改了一些东西要发版（发布生产），如果你是传统项目测试可能怕你改动到了其他的东西影响到了其他的功能（虽然你很确信没改动到，但万一呢？）不得不对淘宝整体的功能都做一遍测试，累死人，而这种形式的测试只需要测试你的购物车的功能，so easy。退一步说，万一你改的代码有问题测试没测出来，那也是影响购物车的功能，用户下单支付不影响。
————————————————
版权声明：本文为CSDN博主「诺浅」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq32933432/article/details/87195037

1.2 SOA的坏处

1. 问题排查不便：比方用户买东西的时候出现了一个报错，很难直接定位到问题出在哪个环节，可能是订单组的代码有问题，也可能是支付组的代码有问题。
2. 沟通不便：如果你们在大公司待过的话就会明白，用户组，订单组，购物车组，支付组等等是分别属于不同的领导管理，出了问题沟通起来很麻烦，甚至你都不知道找谁沟通，也能以前跟你沟通的人后来离职了等等的问题。
3. 性能问题：相对于传统项目的直觉调用，SOA中不管你是使用RPC还是什么HTTP等技术调用，肯定会有性能的损耗，因为网络通信是需要时间的。
4. 关系混乱：当服务越来越多，调用方也越来越多的时候，它们之间的关系就变得非常混乱。
5. 运维难度：随着服务的增多，系统架构会越发复杂，这就给运维层面带来了挑战。
6. 数据一致性问题：单体项目因为数据都在同一个数据库里面，不需要过多的关注分布式事务等问题，SOA就需要关心了。
   ————————————————
   版权声明：本文为CSDN博主「诺浅」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
   原文链接：https://blog.csdn.net/qq32933432/article/details/87195037

1.3 关系混乱可以使用服务治理的方式解决

当服务越来越多，调用方也越来越多的时候，它们之间的关系就变得非常混乱，需要对这些关系进行管理。举例，还是上面的例子，假如我有一个用户服务，一开始有调用方1和调用方2来使用这个服务，后来越来越多，将近上百个调用方，这个时候作为服务方，它只知道提供服务，却不知道具体为谁提供了服务。而对于开发者来说，知道这N多调用方和N多服务方之间的关系是非常重要的。所以这个时候就需要能进行服务治理的框架，比如dubbo+zookeeper，比如SpringCloud，有了服务治理功能，我们就能清晰地看到服务被谁谁谁调用，谁谁谁调用了哪些服务，哪些服务是热点服务需要配置服务器集群，而对这个服务集群的负载均衡也是服务治理可以完成的重要功能之一。
————————————————
版权声明：本文为CSDN博主「诺浅」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq32933432/article/details/87195037

二、什么是微服务

微服务是一种架构模式，叫微服务架构更合理，就是把一个系统中的各个功能点都拆开为一个个的小应用然后单独部署，同时因为小应用多，所以需要一些方法来管理这些小应用。

三、什么是Spring Cloud

spring cloud 为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等。它运行环境简单，可以在开发人员的电脑上跑。

SpringCloud是一个微服务框架的规范。
主要规定如下所示：

1. 服务的注册与发现
2. 负载均衡
3. 服务熔断和限流
4. 智能路由
5. 控制总线
6. 链路监控

三、什么是Spring Cloud Netflix

1、首先，Netflix是一家做视频的网站，可以这么说该网站上的美剧应该是最火的。
2、Netflix是一家没有CTO的公司，正是这样的组织架构能使产品与技术无缝的沟通，从而能快速迭代出更优秀的产品。在当时软件敏捷开发中，Netflix的更新速度不亚于当年的微信后台变更，虽然微信比Netflix迟发展，但是当年微信的灰度发布和敏捷开发应该算是业界最猛的。
3、Netflix由于做视频的原因，访问量非常的大，从而促使其技术快速的发展在背后支撑着，也正是如此，Netflix开始把整体的系统往微服务上迁移。
4、Netflix的微服务做的不是最早的，但是确是最大规模的在生产级别微服务的尝试。也正是这种大规模的生产级别尝试，在服务器运维上依托AWS云。当然AWS云同样受益于Netflix的大规模业务不断的壮大。
5、Netflix的微服务大规模的应用，在技术上毫无保留的把一整套微服务架构核心技术栈开源了出来，叫做Netflix OSS，也正是如此，在技术上依靠开源社区的力量不断的壮大。
6、Spring Cloud是构建微服务的核心，而Spring Cloud是基于Spring Boot来开发的。
7、Pivotal在Netflix开源的一整套核心技术产品线的同时，做了一系列的封装，就变成了Spring Cloud；虽然Spring Cloud到现在为止不只有Netflix提供的方案可以集成，还有很多方案，但Netflix是最成熟的。
————————————————
版权声明：本文为CSDN博主「诺浅」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq32933432/article/details/89918264

3.1 Spring Cloud Netflix组件

1. eureka (提供服务注册与发现功能)
2. ribbon（提供负载均衡功能）
3. Feign（整合了ribbon和Hystrix，具有负载均衡和熔断限流等功能）
4. Hystrix （提供了熔断限流，合并请求等功能）
5. Zuul （提供了智能路由的功能）
6. Hystrix Dashboard （提供了服务监控的功能，提供了数据监控和友好的图形化界面）
7. Hystrix Turbine （Hystrix Turbine将每个服务Hystrix Dashboard数据进行了整合。也是监控系统的功能）
8. spring cloud config （提供了统一配置的功能）
9. Spring Cloud Bus （提供了配置实时更新的功能）
   ————————————————
   版权声明：本文为CSDN博主「诺浅」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
   原文链接：https://blog.csdn.net/qq32933432/article/details/89918264

问题

1.在application类中，main函数要写在最下面，否则main函数会启动失败。

2.ribon模块运行后无法连接到对应的网站。

3.注意application.yml的书写格式，缩进。