微服务的拆分、设计模式、内部结构
一、微服务拆分
x轴处理并发量问题。 y轴解决业务量问题（微服务）。Z轴解决数据量问题。
微服务的拆分，通常根据 系统层面、业务模块层面、功能层面、读写层面、这四个层面来拆分。
1.系统层面拆分
根据公司具有的业务系统进行拆分。这是最表面，最简单的拆分。
2.业务模块层面拆分
业务模块拆分，是根据业务的名称和动词进行拆分。如，对电商系统进行业务模块层面拆分。
3.功能层面拆分
4.读写层面拆分
如果完全按照这四个层面进行拆分，那么微服务将会非常详细，导致拆分的树过于复杂庞大。因此，拆分是没有银弹的。微服务拆分，可以根据团队量来决定。一般来说，一个微服务，应该有3个人来维护。如果团队有12个人，建议将系统拆分成4个微服务。总的来说，服务拆分，应根据公司投入的人力成本。人力成本越多，服务拆分可足够细致。微服务架构设计时，要足够灵活、保证其可扩展性。
二、微服务架构设计模式
以团队管理系统为例 展开说明。
聚合器设计模式
这种设计的特点是 设计简单，性能高效。且解耦、扩展。如果是前后端分离，聚合服务就是各个服务接口功能和业务逻辑。如果前后端没有分离，每个聚合服务，可以是每个页面。
三、微服务内部结构
微服务架构设计，首先就要选择微服务的内部结构。通常其内部结构有如下两种方式：
第一种微服务结构，往往使用webapi，开发平台是.net5或者.netcore。如果想使用跨语言来开发（同时使用多种语言开发微服务，如同时使用java和.net5)，则选用第二种。第二种比第一种的通信性能高。这里我们使用第一种。