云化微服务系统架构云服务微服务

转载

lingyuli 2023-08-22 12:07:09

一.微服务

按照业务拆分，服务的边界明确，将复杂的问题简单化。编码也是按照业务拆分，代码的可读性和扩展性增加。
微服务系统是分布式系统，服务与服务之间没有任何耦合。随着业务的增加，可以根据业务再拆分业务，具有极强的横向扩展能力。随着应用的用户量的增加，并发量的增加，可以将微服务集群化部署，从而增加系统的负载能力。总而言之，微服务系统的微服务单元具有很强额横向扩展能力。
服务与服务之间使用HTTP网络通信协议来通信，单个微服务内部高度耦合，服务于服务之间完全独立，无耦合。这使得微服务可以采用任何的开发语言和技术来实现。
微服务的每个服务单元是独立部署的，即独立运行在某个进程里。微服务的修改和部署对其他服务没有影响
微服务在CAP理论中采用的是AP架构，即具有高可用和分区容错的特点。高可用主要体现在系统7*24小时不间断的服务，它要求系统有大量的服务器集群，从而提高系统的负载能力。另外，分区容错也使得系统更加健壮。

分布式部署，调用的复杂性高：单体应用的时候，所有模块之前的调用都是在本地进行的，在微服务中，每个模块都是独立部署的，通过 HTTP 来进行通信，这当中会产生很多问题，比如网络问题、容错问题、调用关系等。
独立的数据库，分布式事务的挑战：每个微服务都有自己的数据库，这就是所谓的去中心化的数据管理。这种模式的优点在于不同的服务，可以选择适合自身业务的数据，比如订单服务可以用 MySQL、评论服务可以用 Mongodb、商品搜索服务可以用 Elasticsearch。缺点就是事务的问题了，目前最理想的解决方案就是柔性事务中的最终一致性。
测试难度的提升：服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了。这里要强调一点，就是 API 文档的管理尤为重要。
运维难度的提升：在采用传统的单体应用时，我们可能只需要关注一个 Tomcat 的集群、一个 MySQL 的集群就可以了，但这在微服务架构下是行不通的。当业务增加时，服务也将越来越多，服务的部署、监控将变得非常复杂，这个时候对于运维的要求就高了。