从单体架构到微服务架构的演变，微服务带来的挑战是什么？

微服务架构

  业务系统进行服务化改造之后，对于原有的共享类型的业务系统可以拆分成复用的服务而存在，大大提升了整体系统的资源利用率。对于服务的拆分是否越小越好，还是需要结合业务场景进行拆分，最终达到解耦合的目的，可以提升业务的容错性等等内容。

  微服务解决方案，从名字上看是面向服务的，也就是说通过一种服务化的思想来实现。如果说SOA是服务化开发思想的雏形，那么微服务架构其实就是针对可重用的微服务进行了进一步的优化。可以把SOA架构看做是微服务的超级集合，也就是说多个微服务可以组成一个SOA的服务。

  伴随着服务粒度的细粒度化，可能原本的服务会被越拆分越小，一旦服务规模越来越大随之而来的就是构建、发布、运维等工作内容的增加。所以现在出现的很多的技术就是围绕解决这个问题来进行的。例如K8S等等。微服务是一种服务化的实现思想。

与SOA架构最大的不同就是如下的几点。

• SOA关注的是服务的重用性以及解决信息孤岛的问题。
• 微服务则是关注与服务的解耦，从这个方面来看，服务解耦和可重用其实是一样的。但本质上是有区别的，解耦是降低业务场景之间的耦合度，而重用更关注的是服务的复用度。也就是说重用的服务已经是解耦之后的内容了。
• 微服务会更关注DevOps的持续交付上，因为服务细粒度拆分之后，运维的难度随之升级。所以容器化技术就显得尤为重要了。

  如下图所示，我们将每个具体的业务拆分成了可独立运行的服务，每个服务只需要实现特定的功能就可以了，服务之间采用轻量级机制REST API进行通信。这与SOA中的服务的拆分粒度是不同的。例如一个用户服务在SOA架构中就是用户服务，但是在微服务架构中可以将服务继续进行拆分成，用户注册服务、用户鉴权服务等等。实际上微服务的拆分力度没有一个统一的标准，更多的时候是与业务相关联的。微服务并不是拆分得越细越好。

微服务架构带来的挑战

  从单体架构到微服务架构的演变，是技术架构随着产品的复杂度发展而不断进步的过程，最终的目的都是更好地提供服务。使得用户在使用产品的时候获得更好的体验，微服务架构之所以能被广泛地应用其背后可能有它独有的优势。

微服务架构的优点

• 复杂度可控制： 通过共享服务之间的细粒度，一个服务只需要关注一个特定的业务领域解决方案，并且能更好地实现高效快速的开发内容。
• 技术选型灵活：每个微服务可以由不同的语言来提供，可以选择适合自己的技术栈来进行实现。
• 扩展性强：可以根据每个微服务的性能包括使用率等方面来对服务进行一个灵活的扩展。
• 独立部署：由于每个微服务都是可以进行独立运行的，所以可以进行独立的部署。当某个微服务发生变更的时候不需要重新修改其他的服务，代码量比较小，发布更加灵活。
• 容错性：在微服务架构中，如果一个服务器发生故障，可以使用故障隔离手段，将其进行服务隔离、服务降级等操作。

微服务架构面临的挑战

  微服务架构只是一种架构模式，并不能解决所有架构问题。虽然本身有很多的优势的地方，但是在使用过程中，经常会遇到分库分表，API交互，大量的微服务的运维与开发等问题。主要有如下的一下问题

• 故障排查：一次请求经历了很多的不同业务场景的微服务，交互的链路很长，每个微服务会产生自己的日志，这种情况下出现一个问题的时候开发人员在查找过程中会比较困难。
• 服务监控：在一个单体架构中很容易实现服务的监控操作，因为所有的服务资源都在一个Jar包中。但是在微服务架构中，服务的监控操作其实本身就是一件很耗资源的事情，在几百个微服务的架构中进行全链路的监控，算上服务本身对于资源的消耗，为了监控这些服务的运行情况二次消耗的资源也是比较大的。
• 分布式架构的复杂性问题：微服务系统本身是一个分布式系统，既然是分布式系统那么不可避免的就要解决分布式系统CAP问题，包括远程通信的过程中网络上消耗等无法避免的情况的出现。
• 服务依赖：随着服务的不断增加，会存在服务之间的相互依赖，在单体应用中服务之间的依赖只需要改变模块之间的依赖关系就可以了，但是在微服务之中不同的服务之间通过这种方式很难实现依赖的完全拆解。所以需要对于依赖进行一个合理的划分。
• 运维成本：微服务架构中，成百上千的微服务的正常运行，离不开运维人员的支持，但是在单体应用中运维人员只需要进行简单的运维操作就可以，在微服务架构中就会有很多的问题、如何快速部署、如何统一进行服务的管理，这就需要SRE工程师的不断优化部署架构等内容。

如何实现微服务架构

微服务架构图

  现在网上这种微服务架构图一抓一大把，但是微服务到底如何实现，这个是关键性的问题。

  微服务架构实现需要实现的就是服务的结合操作。随着业务的发展支持微服务的组件也会越来越多，导致微服务之间的调用关系原来越复杂，同时服务之间的通信问题也就会变得复杂，难以管理，然后再要考虑到重试、容错、服务降级等情况。这个时候就需要服务治理的出现，将服务之间的相互依赖关系转化为对于服务注册中心的依赖关系。除此还要考虑如下的一些问题

• 分布式配置
• 服务路由
• 负载均衡
• 服务熔断限流
• 全链路监控

  以上的每个问题都需要一个对应的技术栈来解决与之对应的问题。首先考虑的就是用现成的东西还是自己有研发能力进行研发，那种解决方案更好，就需要对每种解决方案进行讨论进行最终的解决方案的操作。

  现在很多的公司都是有适合自己公司的一套技术体系的东西，就算是使用了开源的中间件，后期也会因为业务的需求进行定制化的开发，毕竟很多的东西，总结出来只是普适性的内容。但是真正适合自己公司业务的内容还是需要经过公司的业务验证才能进行确定的。

  后续的分享中也会带着大家进行一个深入的探讨。