微服务架构设计的关键可以从下面几个点考虑

　　对于微服务架构设计，我在前面文章都有谈到过相关内容，今天再对微服务架构设计中的一些关键点做下整体说明，要明白远远不是采用了类似SpringCloud微服务开发框架，或者说采用了Http Rest接口服务就是微服务架构。
　　更加重要的还是业务能力的组件化或者叫微服务模块化，组件能力的接口服务化。也就是微服务架构设计的关键点不在于技术框架和实现，而在于前期的业务和技术建模。基于业务交互分析划分微服务
　　微服务模块划分的颗粒度是否合理将直接影响到后续微服务模块的开发集成和实施难度，看到很多例子就是一个本来很小的业务系统居然会划分出20多个微服务模块，每个模块全部采用单独的容器部署。
　　这个在互联网应用里面可能适用，但是在企业微服务架构转型里面一定不适合。模块划分越细，模块间接口交互和集成就越复杂，后续微服务的运维管控治理就越难。
　　如何来划分？
　　还是我原来建议的除掉标准的类似4A，流程引擎技术服务等微服务模块，一个传统的业务系统建议最多拆分为6到8个微服务组件，对于纵向流程工单驱动型由于本身耦合小可以划分的更细，但是其它类似核心业务数据驱动型都不要划分太细。
　　对于微服务划分的方法，可以参考我前面发布过的文章，一种是基于传统企业架构规划思路进行业务架构和数据架构规划，通过CRUD分析拆分。一种是基于领域建模思想，通过业务梳理进行上下文边界识别。
　　对领域模型和上下文边界分析来划分微服务的再思考
　　中台规划中微服务粒度究竟应该如何划分？你可以从以下几点考虑面向接口开发同时识别粗粒度接口
　　微服务在架构设计阶段除了技术架构外核心就是两点：其一是划分微服务模块
　　其二是识别和定义粗粒度微服务API接口
　　注意微服务模块间的接口要提前进行识别和定义，从顶向下面向接口开发，这本身也是传统架构设计就遵循的原则。一定不能是一开始不定义接口，后续各个模块开发到哪里了发行接口缺少再临时仓促定义，这个带来的最大问题就是接口粒度管理失控，后续运维也失控，导致大量的接口重复定义等。
　　如果你是采用Http Rest接口，那么你更要了解面向资源设计和领域建模的概念，怎样定义才算得上是面向资源的，而部署简单的随便定义Http API操作。
　　对于面向API接口规划和设计思路，可参考：
　　微服务架构下的API接口驱动开发，设计和集成在架构设计阶段就完成数据库拆分
　　注意在微服务架构设计阶段就一开始就应该完成数据库拆分，每个微服务模块对应独立的数据库，一定要注意微服务一定不是简单的应用组件拆分，而是也包括了后端的数据库也有拆分，这样才是完整意义上的微服务架构。
　　同时拆分后的数据库间不应该有交互和集成，所有的交互和集成都应该通过应用组件层的API接口服务进行。只有这样才是完整意义上的微服务架构。
　　对于该点，我在前面文章里面也提出了微服务业务域的概念，即可以多个应用层的微服务划分到一个业务域共享同一个数据库，减少数据库划分太细导致的大量集成和分布式事务问题。搞清微服务注册中心和微服务网关区别
　　在一个完整的微服务架构里面涉及到微服务注册中心和微服务网关，务必注意到两个组件的区别并按需使用。
　　简单来说就是一个微服务架构应用内部所有的微服务模块组件之间的接口交互都只需要通过注册中心来完成即可，这种方式是性能最佳，去中心化的方式。
　　当一个微服务架构应用需要和外部交互，或者说需要开放能力给外部业务系统使用的时候才需要将API接口服务接入到微服务网关或API网关。
　　微服务网关核心起到服务代理，隔离，各种安全，日志，流控等拦截作用。
　　一个在微服务应用内部使用的Http API接口是否完全也适用于直接暴露和注册到微服务网关，这个需要根据情况来分析和判断，因为暴露到网关上的API接口往往在规范性和管控上有更加严格的要求。
　　微服务去中心化架构下为何还要用API网关？做好开发团队划分和微服务划分之间匹配
　　在微服务架构设计做好了微服务模块划分后，另外一个重点工作就是做好开发团队的划分和匹配工作，按道理这个不属于微服务架构设计的内容，但是属于整个研发过程和项目管理的内容。
　　开发团队的划分基本要做到和微服务模块划分匹配，能够完全隔离和松耦合是最好。
　　要明白，如果一个人负责多个微服务模块，那我们原来定义的微服务模块间的接口规则，交互规则，技术标准规范很难真正做到彻底执行。
　　即多个微服务模块间协同变成一个开发人员内部管理的事情，那么开发就容易怎么方便怎么来，而忽视了关键的架构规则和约束。也就是到最后你会发现，分配给一个人负责的多个微服务模块，本身一开始是松耦合的设计，但是最好完全变样为难以拆分的紧耦合关系。面向产品集成和持续集成而设计
　　在微服务架构设计的时候，必须要考虑到产品集成和持续集成，对于持续集成可以参考标准的持续集成方法，也可以参考DevOps标准过程体系以实现持续集成和持续交付，当然在整个过程中可以和容器化PaaS平台融合，进一步实现持续交付过程的自动化。
　　另外在整个架构设计中的模块划分和接口设计的时候，还需要考虑到整个产品集成顺序，即一个大系统划分为了多个微服务模块，他们之间的构建顺序，集成顺序究竟是如何的？
　　为了更好地实现产品集成，原则上应该是基于完整的业务流生命周期，模块之间更多的是由上游流程到下游流程进行逐层集成，同时尽量要避免双向集成导致后续集成测试很难进行集成和组装。
　　在产品集成的时候究竟应该先构建哪个？先集成哪个？这些也是在架构设计的时候需要考虑的问题。
　　从CI/CD持续集成部署到DevOps研发运维一体化
　　微服务下产品集成和集成测试框架流程面向业务和应用监控运维而设计
　　要注意在微服务架构下实际上是独立自治的微服务模块变多，接口变多，集成关系更加复杂，这些都直接导致了后续业务和应用监控更加复杂。
　　很多企业在进行微服务架构转型的时候，由于后期的自动化监控运维能力跟不上导致最终转型中出现大量的问题无法解决，这些也是在架构设计时要考虑的。
　　即在进行微服务架构设计的时候，要基于DevOps的思想，将很多可监控，可运维需求作为关键的非功能性需求纳入到架构设计中，在各个微服务模块的设计，微服务模块间的接口服务设计的时候都需要加入这些设计原则和关键属性，以方面后续进行业务监控和服务链监控，同时在业务出现问题的时候能够快速定位。