此篇文章是个人以及公司微服务平台落地的一些总结吧。
微服务是什么？
参考链接： https://martinfowler.com/articles/microservices.html
这一点不需要过分罗嗦，简单来说就是将当前单体架构或者SOA架构拆分为一个个的服务模块，每个服务模块各司其职的同时，内部又可以通过RPC 互相调用。微服务比SOA的划分粒度更细，更注重去中心化以及DevOps。其优点还是比较多的，比如各个服务模块的边界性，多语言支撑，以及持续交付的自动化容器部署。缺点呢，在我看来第一点是所有分布式程序都必须面对的，弱化了强一致性并且将系统复杂度提升了，第二点就是系统复杂度的提升对开发人员的数量以及质量还有运维基础设施的建设要求都比较高了。
我们适合采用微服务架构吗？
参考链接：https://www.rowkey.me/blog/2019/05/30/msa/
对于 某些小型企业在业务复杂度以及用户量不多的业务初期的情况下我们大可不必采用微服务架构，因为就前边的优缺点对比而言，采用微服务的小公司对于人员的投入可能会大于它的收益。系统业务越复杂，微服务带来的收益越大。所以前期先采用模块化也是不错的开发方案。如果有确实的用户体量支撑以及专业的开发团队可以考虑微服务。
微服务的一些注意事项
开发之前的：DevOps团队
微服务是务必需要DevOps 团队支撑的，因为其架构复杂性，我们必须依托于容器技术考虑自动化的持续交付，具有良好的持续交付能力，包括全链路追踪、快速环境提供和自动化部署。
开发中：服务模块的拆分
服务的拆分就是将系统整体解耦为一个个服务，服务之前需要职责单一，没有耦合。这就要求首先对系统的整体业务非常熟悉，服务拆分也不是系统开发一开始就规划好的，需要在服务开发中进一步理清楚各个服务的边界，不至于到最后各个服务成了一团乱麻。最初的拆分都是基于业务的，针对不同的业务逻辑来拆分不同的服务模块。其他的就是以及扩展性和服务性能的拆分，举个例子，比如在每个服务中都需要大文件上传下载等管理功能，我们便可以把文件服务拆分出来，而且也不建议其他微服务调用该服务，而是将该服务直接提供给网关或者前台直接调用，因为大文件的上传耗时耗内存，如果在服务之前调用，那么会降低系统的可用性。
开发中：分库分表
前面我们讲了服务拆分，对应到数据库就是分库分表，一般也是按照业务纵向分库垂直分表。如果切分不合理的话会导致众多的内部服务调用以及分布式事务，系统复杂度进一步提升
1）. 纵向分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库，做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与“微服务治理”的做法相似，每个微服务使用单独的一个数据库。
2）. 垂直分表是基于数据库中的列进行，某个表字段较多，可以新建一张扩展表，将不经常用或者字段长度较大的字段拆出到扩展表中。在字段很多的情况下，通过大表拆小表，更便于开发与维护，也能避免跨页问题，MYSQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的开销。另外，数据库以行为单位将数据加载到内存中，这样表中字段长度越短且访问频次较高，内存能加载更多的数据，命中率更高，减少磁盘IO，从而提升数据库的性能。
当其中某个服务或者某几个服务难以再细粒度的垂直切分或切分后数据量行数依然巨大，存在单库读写，存储性能瓶颈，这时候需要进行水平切分。
水平切分为库内分表和分库分表，是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果。
库内分表只解决单一表数据量过大的问题，但没有将表分布到不同机器的库上，因些对于减轻mysql的压力来说帮助不是很大，大家还是竞争同一个物理机的CPU、内存、网络IO，最好通过分库分表来解决。
开发中：服务容错、服务治理、服务发现
这里主要就是按照目前成熟的微服务架构提供对应的注册中心，服务熔断机制进行开发了，目前成熟的springcloud 生态都具备了，其实难点还是在于前面的服务拆分上。
开发后： 服务监控、服务链路、性能调优、服务运维
其中一部分还是需要DevOps 去做的，服务自动监控以及服务运维。链路追踪现在各个服务框架基本上都提供，最后的性能调优主要是针对平时的并发量高的服务性能进行提升，比如jvm 虚拟机性能调优，服务器io调优，容器性能调优。
微服务总结
总体而言，我们需要掌握了解微服务技术，这是互联网分布式应用的一次探索，里面提供了很多先进的思想，跟随微服务而来的是数据中台和Service Mesh，然后是 serverless,各个公司的架构师可以根据自己公司的业务发展以及用户群体、用户量选择是否采用微服务或者其他分布式技术代替自己的单体化和SOA架构。
