这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天.
本次课主要是讲了微服务架构篇，将之前老师讲的课程给细化了。
首先提及了微服务的发展史。从单体架构开始，到后来需求增加就出现了垂直架构，再到分布式架构，并在提及SOA框架，最后引入微服务框架。
单体架构性能最高，但是所有组件全部集成在单个项目中，所以模块与模块之间会相互关联，维护困难，增加一个组件就需要考虑其他相关的组件，不利于开发。
垂直架构是对单体架构的改进，将业务模块分别开发，将整个项目按照业务线垂直划分，所以业务之间可以独立维护。但是不同业务之间冗余，而且每个业务本身还是单体架构，所以也不利于维护。
上图是分布式架构，在垂直架构的基础上，将非业务间的模块单独抽取开发，划分为单独的一层，该层为服务层。优势可以减少很多冗余代码，每个服务间更好进行维护，但是服务层的模块若出现问题，则会导致很多业务模块不可用。调用关系非常复杂，所以继续改进为SOA架构
上图是SOA框架，加入了服务注册中心，可以很好的做一层中间代理以协调业务代码与公共代码之间的关系，从一定的角度而言依赖性减弱，实现了解耦，利于维护。但是服务中心会导致整个架构的中心化，即该层非常重要。使得整个系统设计仍然是中心化。
上图为微服务框架，将每个业务都服务化，每一个业务都可以成为一个服务，可以拥有多个实例，业务的独立实现使得业务与业务之间实现了很好的隔离性。但因为业务分的非常细致，所以维护起来困难，拥有分布式所拥有的问题。
上图为基本概念。其中服务为具有相同逻辑的实体，即每个运行实体代码相同，所以一个服务中可以存在多个实例。每个实例可以对应一个或多个进程，进程之间所分配的ip与端口号不同。多个实例组建的整体为一个集群等。
在单体服务中，模块之间的通信是以函数调用进行通信，但是在微服务中，各模块进行分离，所以通信一般为网络传输，所以单体服务运行更快。
随后老师讲了服务发现与服务注册。由于微服务架构中将业务分为了多个小服务进行相互通信，所以当a服务中的实例需要访问b中的实例时，需要进行对应的ip及端口进行查找。所以增加一个统一的服务中心，当a调用b时会在服务中心进行查找，然后服务中心进行端口及IP的分配，多实例是为了实现均衡负载，防止访问过多而崩溃。
当实例需要更换时先在服务中心中将对应的ip进行删除，此时的访问压力会平分给剩余实例。当对应实例被服务中心删除后，服务a就无法调用服务b被删除的实例。更换新的实例后，该实例会进行一个健康检查，类似给一组测试查看是否运行正确。通过检测后将ip及端口注册到服务中心，实现了实例的动态更换。
当需要更新服务时，软件更新，此时可能需要批量对实例进行更换，当服务进行更换时则系统会存在短暂时间不可用，此过程在实际中是不被允许的。所以可以一个一个的对实例进行更换，但在三个实例均衡的情况下，突然下线一个实例可能会造成服务抖动，若更新后的实例出现bug，还需要对原实例进行回滚，回滚到原正常可运作实例状态。
常见更换服务状态下老师讲解了两种更换方式：1.蓝绿部署 2.灰度服务
蓝绿部署是创建双倍的资源，先讲绿色部分停掉，剩余的由蓝色部分继续服务，然后更换绿色区域，再将服务中心的地址转移到绿色区域。有时候更换服务会造成服务器压力过大，所以会检测用户使用流量情况，如用户在凌晨使用情况较少，则会在凌晨进行更新发布，以此减小负载。
灰度发布则是将实例依次一个一个进行更换，但是一般不使用该情况，因为当更换后的服务出现问题时回滚操作麻烦，在每一次更换实例的情况下都有可能会出现问题，从0-99%进行更换中都可能会突然发现新更换的实例出现bug而不好回滚，所以一般情况还是使用蓝绿部署。
随后老师提到了实际中容易忽视的稳定性问题，不论开发的程序是否完全正确，但是项目总会出现各种问题，因为有实际的耗材，也许缆线故障，黑产攻击等。一般解决的情况有四种，对于请求过大流量的服务进行限流，当遇到网络延迟故障后则拒绝连接，过一段时间再进行重试，对于服务端自身cpu压力过大则直接拒绝请求，或者降级处理，优先处理比较重要的服务。
最后老师讲了关于稳定性中重试会存在的问题以及对应解决方案。整体的讲课让人更加深入微服务概念，了解微服务相关的架构，了解组件结构，服务中包含多个实例，实例之间的交互过程，以及提到最重要的服务注册以及服务发现概念。之后在程序中体现应该更能加深印象。
