在每次去做一个项目的时候，我们都会考虑业务的划分和技术的选型来保证以后的迭代优化过程。
那么在这之前，先总结一下一般常用的架构。

单体结构
单体架构即将所有的功能业务放到一起，统一打包部署放到一个web容器中。
优点：简单易构建，容易进行测试。
缺点：在遭遇到项目异常时，因为业务耦合的原因，修改耗时时间较长，且版本更新也较为复杂，编译部署时间也长，在访问量大的情况下，性价比不高。

而为了解决单体架构带来的缺点，微服务架构诞生。

微服务架构
SOA(面向服务架构)中的一种架构，将业务功能逐一划分为一个个服务，采用不同的技术，部署在多个服务器上，微服务之间耦合度降到最低。
例如在商城项目中，就可以分为订单微服务，用户微服务，商品微服务，后台管理微服务等等。
优点：各个服务之间可以自身进行管理，不涉及其他服务，易于拓展，开发效率高，可以对每个服务采用不同的技术选型，帮助提高性能，在版本更新时也不会对其他服务造成影响。
缺点：增加了架构的复杂度，不同服务之间发起调用需要使用RPC或REST等技术通讯，当然这也会带来服务之间的一系列问题。

尽管微服务有着这些那些的缺点，但依旧不能遮掩住服务自治等等的优点，也正是因为这些优点，现在的企业才会选择微服务架构进行项目的构造。

既然选择好了项目架构，那么下一步毫无疑问就是对于微服务的划分了，我们应该如何根据需求划分微服务呢？下面就让我们来讲讲划分的方法。

微服务的划分
对于一个架构师来说，划分微服务靠的是经验，架构师眼里不分对错，只谈合适与否。
而作为一个刚入行业的小白，该如何知道正确的划分微服务呢？

DDD(领域驱动建模进行业务建模)
从需求和业务中获得抽象的实体(像是用户、订单和商品等等)，根据这些实体之间的依赖关系划分限界上下文，然后并对之进行检验，最后从上下文向微服务转化，得到一个项目的总架构。
如何抽象和划分？

既然已经成功划分完了微服务，那么就要在数据库中建库建表了。一个高并发、大流量的项目，必然会涉及到分库分表来提高性能，接下来我们从三个角度来分析一下分库分表这件事。

分库分表

  • WHY 为什么需要分库分表：在单个数据库下，服务器的连接数、内存大小都有着硬件限制，所以存在着性能瓶颈，打破瓶颈的方式就需要分库分表。
  • WHAT 什么是分库分表：将一个数据库拆分成多个数据，将一张表拆分成多张表，分别部署在多台服务器上。
  • HOW 怎么分表分库：
  • 垂直拆分：将一张表多个字段拆分多张表多个字段，主表存放查询的热点字段，副表存放剩余字段；将不同表放到不同的数据库中，有利于微服务的业务场景拆分。
  • 水平拆分：将一张表根据数据进行拆分，例如2000w的数据，拆分成两个1000w的表；将表的数据根据某些规则分别分到不同服务器上的数据库中。
  • 混合拆分：根据垂直拆分拆分业务，再水平进行分库提高性能。

分库分表有好处当然也有坏处，查询数据在不同数据库，这时候就需要用到分布式事务；跨库关联查询，就要多次查询实现；多节点的排序问题，可能需要放到应用解决；分页问题；分布式ID的设置。