微服务-微服务Alibaba-Nacos注册中心实现

1. 系统架构的演变

俗话说， 没有最好的架构，只有最合适的架构。 微服务架构也是随着信息产业的发展而出现的最有普 遍适用性的一套架构模式。通常来说，我们认为架构发展历史经历了这样一个过程：单体架构——> 垂直架构 ——> SOA 面向服务架构 ——> 微服务架构。

1.1 单体架构

        互联网早期，一般的网站应用流量较小，只需一个应用，将所有功能代码都部署在一起就可以，这样 可以减少开发、部署和维护的成本。比如说一个电商系统，里面会包含很多用户管理，商品管理，订 单管理，物流管理等等很多模块，我们会把它们做成一个web项目，然后部署到一台tomcat服务器上

很多传统互联网公司或者创业型公司早期基本都会采用这样的架构，因为这样的架构足够简单，能够 快速开发和上线。而且对于项目初期用户量不大的情况，这样的架构足以支撑业务的正常运行。

优点：

         项目架构简单，小型项目的话， 开发成本低

        项目部署在一个节点上， 维护方便

缺点：

         全部功能集成在一个工程中，对于大型项目来讲不易开发和维护

        项目模块之间紧密耦合，单点容错率低

        无法针对不同模块进行针对性优化和水平扩展

1.2 垂直架构

        随着用户量越来越大，网站的访问量不断增大，导致后端服务器的负载越来越高。 用户量大了，产品 需要满足不同用户的需求来留住用户，使得业务场景越来越多并且越来越复杂。

我们可以从两个方面进行优化：

通过横向增加服务器，把单台机器变成多台机器的集群。

按照业务的垂直领域进行拆分，减少业务的耦合度，以及降低单个war包带来的伸缩性困难问题。

优点：

         系统拆分实现了流量分担，可以针对不同模块进行优化

        方便水平扩展，负载均衡，容错率提高

        系统间相互独立，互不影响，新的业务迭代时更加高效

缺点：

         服务之间相互调用，如果某个服务的端口或者IP地址发生改变。调用的系统得手动变化

        服务之间调用方式不统一，基于httpclient,webservice，接口协议不统一

        搭建集群之后，实现负载均衡比较复杂。比如：内网负载，在迁移得时候会影响调用方的路由，导致线上故障

        服务监控不到位

1.3 SOA架构

为了让大家更好地理解SOA，我们来看两个场景：

        • 假设一个用户执行下单操作，系统的处理逻辑是先去库存子系统检查商品的库存，只有在库存足够的 情况下才会提交订单，那么这个检查库存的逻辑是放在订单子系统中还是库存子系统中呢？在整个系 统中，一定会存在非常多类似的共享业务的场景，这些业务场景的逻辑肯定会被重复创建，从而产生 非常多冗余的业务代码，这些冗余代码的维护成本会随着时间的推移越来越高，能不能够把这些共享 业务逻辑抽离出来形成可重用的服务呢？

        • 在一个集团公司下有很多子公司，每个子公司都有自己的业务模式和信息沉淀，各个子公司之间不进 行交互和共享。这个时候每个子公司虽然能够创造一定的价值，但是由于各个子公司之间信息不是互 联互通的，彼此之间形成了信息孤岛，使得价值无法最大化。

基于这些问题，就引入了 SOA（Service-Oriented Architecture），也就是面向服务的架构 。在SOA 中，会采用ESB（企业服务总线）来作为系统和服务之间的通信桥梁，ESB本身还提供服务地址的管 理、不同系统之间的协议转化和数据格式转化等。调用端不需要关心目标服务的位置，从而使得服务 之间的交互是动态的，这样做的好处是实现了服务的调用者和服务的提供者之间的高度解耦。

         总的来说，SOA主要解决的问题是：

                 信息孤岛

                共享业务的重用

优点:

         使用治理中心（ESB）解决了服务间调用关系的自动调节

缺点:

         服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )

        服务关系复杂，运维、测试部署困难

1.4 微服务架构

        微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步，它更加强调服务的"彻底拆分"。 面向服务（SOA）和微服务本质上都是服务化思想的一种体现。如果SOA是面向服务开发思想的雏形，那么微服务就是针对可重用业务服务的更进一步优化，我们可以把SOA看成微服务的超集，也就 是多个微服务可以组成一个SOA服务。伴随着服务粒度的细化，会导致原本10个服务可能拆分成了 100个微服务，一旦服务规模扩大就意味着服务的构建、发布、运维的复杂度也会成倍增加，所以实施 微服务的前提是软件交付链路及基础设施的成熟化。

由于 SOA 和 微服务 两者的关注点不一样，造成了这两者有非常大的区别：

        1. SOA关注的是服务的重用性及解决信息孤岛问题。

       2. 微服务关注的是解耦，虽然解耦和可重用性从特定的角度来看是一样的，但本质上是有区别的，解耦是降低业务 之间的耦合度，而重用性关注的是服务的复用。

       3. 微服务会更多地关注在DevOps的持续交付上，因为服务粒度细化之后使得开发运维变得更加重要，因此微服务 与容器化技术的结合更加紧密。

微服务架构就是将每个具体的业务服务构成可独立运行的微服务，每个微服务只关注某个特定的功

能，服务之间采用轻量级通信机制REST API进行通信。

英文: https://martinfowler.com/articles/microservices.html

https://microservices.io/patterns/microservices.html

中文: http://blog.cuicc.com/blog/2015/07/22/microservices

优点：

        复杂度可控： 通过对共享业务服务更细粒度的拆分，一个服务只需要关注一个特定的业务领域，并通过定义良好 的接口清晰表述服务边界。由于体积小、复杂度低，开发、维护会更加简单。

        技术选型更灵活： 每个微服务都由不同的团队来维护，所以可以结合业务特性自由选择技术栈。

        可扩展性更强： 可以根据每个微服务的性能要求和业务特点来对服务进行灵活扩展，比如通过增加单个服务的集 群规模，提升部署了该服务的节点的硬件配置。

        独立部署： 由于每个微服务都是一个独立运行的进程，所以可以实现独立部署。当某个微服务发生变更时不需要 重新编译部署整个应用，并且单个微服务的代码量比较小，使得发布更加高效。

        容错性： 在微服务架构中，如果某一个服务发生故障，我们可以使故障隔离在单个服务中。其他服务可以通过重 试、降级等机制来实现应用层面的容错。

缺点：

微服务架构不是银弹，它并不能解决所有的架构问题。 在拥抱微服务架构的过程中，我们经常会遇到 数据库的拆分、API交互、大量的微服务开发和维护、运维等问题。即便成功实现了微服务的主体，也 还是会面临下面这样一些挑战。

        故障排查： 一次请求可能会经历多个不同的微服务的多次交互，交互的链路可能会比较长，每个微服务会产生自 己的日志，在这种情况下如果出现一个故障，开发人员定位问题的根源会比较困难。

        服务监控： 在一个单体架构中很容易实现服务的监控，因为所有的功能都在一个服务中。在微服务架构中，服务 监控开销会非常大，可以想象一下，在几百个微服务组成的架构中，我们不仅要对整个链路进行监控，还需要对 每一个微服务都实现一套类似单体架构的监控。

        分布式架构的复杂性： 微服务本身构建的是一个分布式系统，分布式系统涉及服务之间的远程通信，而网络通信 中网络的延迟和网络故障是无法避免的，从而增加了应用程序的复杂度。

        服务依赖： 微服务数量增加之后，各个服务之间会存在更多的依赖关系，使得系统整体更为复杂。假设你在完成 一个案例，需要修改服务A、B、C，而A依赖B，B依赖C。在单体式应用中，你只需要改变相关模块，整合