在当前项目中微服务如火如荼，已经是开发和架构主流，对于服务架构更是五花八门。今天根据个人对于微服务的理解特意整理自己理解的微服务架构图例，在绘制此图事考虑过很多，目的在于不想后期每个项目都单独的画一个图例进行结构说明，希望有一个通用的架构，其他各系统都直接遵照执行即可，在概要设计章节可以覆盖更广阔的业务系统。如下:
原图连接地址: www.processon.com/view/5d70cc…，可以直接在线克隆，根据自己的需求进行改动。
架构说明:
1. 服务管理(4个中心)
图例中主要提出4个中心: 注册、配置、认证、监控，主要是对整个微服务集群正常运行起到支撑作用同时也至关重要。
内部服务统一都注册到注册中心，对其他服务进行接口暴露；统一通过配置中心对服务本身的参数进行更新维护，所有的外部访问统一都会通过网关进行认证授权；所有服务的运行统一汇总到监控中心，可以直接查看到各个服务的健康度。
2. 统一网关
如上所示，系统不限于采用什么分布式框架和技术，对外统一通过网关提供API接口或其他形态如WebSockt，MQTT等形式；网关中心主要负责接收外部请求，通过授权中心提供的数据对请求进行访问认证，以及接口限流策略控制，最后当各种规则都通过的请求，才被路由到后端的实际微服务集群。
3. 业务微服务
每个业务微服务，根据实际业务领域进行拆分(此处建议参考领域建模思想DDD)，每个微服务可以有自己独立的DB，对外或是依赖其他的服务接口统一都通过REST API形式进行对外暴露或依赖。
4.内部交互
微服务的内部交互通过两种方式：一种通过接口直连的方式进行，进行同步调用，这种方式在一定程度上是可以为后期业务的链路监控提供便捷，同时也可满足绝大部分业务需要。另一种通过消息中间件实现内部服务之间的异步调用,如果需要和第一种一样需要实现链路监控，就需要在消息协议体中加入请求ID并进行跟踪监控，通过采用消息的异步调用，需要根据业务自身特点进行选择。
5.对外异构系统集成
图中Open API 主要是对外开放接口，从而异构系统之间的集成，对外提供的接口同样需要经过内部认证中心的授权，否则是不能调用。对外接口存在形态可以是多种，比如:http,mq,websocket等，可以根据实际业务选择性调用
6. DevOps
开发运维部署方面， 所有服务的开发实现和部署都基于DevOps，从服务虚拟化，容器化，代码静态扫描，自动测试，自动构建和自动发布等，均有集成的DevOps工具和环境完成。
7.监控维护
系统正式运行由统一的监控运营平台进行监控，通过专业的日志分析平台提供日志监控和分析，通过专业的安全策略实现安全防护，同时由任何服务监控或是异常统一都有告警系统进行告警。此处建议采用PAAS层服务进行实现，比如阿里云、微软云和AWS等均有提供对应的服务。此处更多是基于硬件，虚拟机，网络以及安全攻击等方面的监控，服务的监控中心区别不一样。
总结
综上所述，按这样的思路考虑架构，其思路上基本上可以容纳很多概念，在描述架构的同时不局限于具体技术实现，架构的设计其实可以提出对于技术选型的参考，因为架构中多少都透露出对于技术的需求，而不是对于某一个技术组件的强依赖。
