什么是微服务

什么是微服务？

简单举例：一艘航空母舰作战能力虽然很强，但是弱点太明显，就是防御能力太差，单艘的航空母舰很少单独行动，通常航空母舰战斗群才是主要军事力量，你可以把单艘航母理解为的单体应用（防御差，机动性不好），把航母战斗群（调度复杂，维护费用高）理解为微服务。

大部分的开发者经历和开发过单体应用，无论是传统的 Servlet + JSP，还是 SSM，还是现在的 SpringBoot，它们都是单体应用，那么是什么问题，导致要抛弃单体应用转向微服务架构？主要问题如下：

部署成本高（无论是修改1行代码，还是10行代码，都要全量替换）

改动影响大，风险高（不论代码改动多小，成本都相同）

因为成本高，风险高，所以导致部署频率低（无法快速交付客户需求）

当然还有例如无法满足快速扩容，d性伸缩，无法适应云环境特性等问题，都是微服务架构要解决的问题。

关于微服务的课程，建议您在B站搜索我们官方账号“尚学堂”进行学习！免费的课程哟！

希望能帮到您，望采纳！！

为已经添加好的数据表添加外键：

语法：

alter table 表名 add constraint FK_ID foreign key(你的外键字段名) REFERENCES 外表表名(对应的表的主键字段名);

例：

alter table tb_active add constraint FK_ID foreign key(user_id) REFERENCES tb_user(id)

//FK_ID是外键的名称

/

CREATE TABLE `tb_active` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`title` varchar(100) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,

`content` text CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,

`user_id` int(11) NOT NULL,

PRIMARY KEY (`id`),

KEY `user_id` (`user_id`),

KEY `user_id_2` (`user_id`),

CONSTRAINT `FK_ID` FOREIGN KEY (`user_id`) REFERENCES `tb_user` (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=latin1

/

我们公司使用的就是微服务加分库分表，一般来说如果应用系统出现性能瓶颈或者业务代码耦合过重，可考虑使用微服务架构，而后端的数据库通常使用读写分离，双主互备或者是分库分表来实现性能的提升和数据服务的高可用。

在数据分布在不同的数据库服务器的带来良好性能的同时，新的问题也随之而来，比如说数据一致性的保证，性能监控，数据存取复杂等，而较为突出的就是数据跨库问题！数据分布在不同的节点上，导致原来的连接查询需要跨库，字段的主键难以保证唯一，跨库的事务处理复杂，下面逐一解决:

1，连接查询(join)问题:因为库表分布在不同的机器上，连接查询失效。

解决办法:

①，代码解决:根据某个字段进行hash的方式进行分库分表，保证落在一个库中的类似表中(比如aa_00t_user_0000和aa_00t_member_0000)，然后基于这样的规则在代码中进行连接查询语句书写！

②，同步:将常用的，需要的字段同步到一个库中进行联合查询！

③，冗余:在一个库中冗余更多的连接查询需要的字段，保证全部数据都能查询到！

2，唯一主键:如果使用传统的自增等方式，多库中的主键id势必重复，所以需要对唯一性加以控制！

解决方法:UUID(根据机器ID，时间等)，redis(单线程保证不重复)，snowflake算法！

3，分布式事务:

1，TCC:try控制业务代码流程，Confirm确认事务的正确性，cancel取消失败的事务！

2，基于消息系统的一致性方案:单节点事务完成后，通过发送消息保证事务提交，如果失败可通过重试，任务补偿等方式保证数据一致性！

总的来说，分布式系统有着很多以往不存在的问题，还需要具体问题具体分析，可一起交流，更多的技术分享，敬请关注。。。

微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。

微服务是指开发一个单个 小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。

微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务。

微服务架构的优点：

每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。

微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。

微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。

微服务能使用不同的语言开发。

微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。

微服务允许你利用融合最新技术。

微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。

微服务架构的缺点：

微服务架构可能带来过多的 *** 作。

需要DevOps技巧 (>

可能双倍的努力。

分布式系统可能复杂难以管理。

因为分布部署跟踪问题难。

当服务数量增加，管理复杂性增加。

微服务适合哪种情况：

当需要支持桌面，web，移动智能电视，可穿戴时都是可以的。

甚至将来可能不知道但需要支持的某种环境。

微服务可以通过使用Redis来实现同步。Redis是一种高性能的内存数据库，可以将数据存储在内存中，从而提高访问速度。因此，它可以用来实现微服务之间的数据同步，从而提高微服务的性能。Redis可以提供一致性，可靠性和可伸缩性，从而使微服务之间的数据同步更加可靠。此外，Redis还可以提供高性能的数据查询和更新功能，从而使微服务之间的数据同步更加高效。总之，Redis可以有效地实现微服务之间的数据同步，从而提高微服务的性能。

以上就是关于什么是微服务全部的内容，包括:什么是微服务、微服务 数据库 怎么设计外键关联怎么搞、Java互联网架构-微服务架构如何解决跨库问题的思路与方案等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！