我的理解应用架构是业务架构的落地，微服务架构下平台的应用架构设计，实质是根据业务来明确应用微服务的边界。因此业务不同，应用架构图也不同。但是基本框架应该相差不大。

        其划分原则莫过于高内聚、低耦合。这个跟接口设计是一致的。我们总是想降低业务之间的关联程度。简单的道理，就是发布一个微服务，尽量不要少影响业务。业务耦合性很强，维护起来成本大，发布上线对用户使用也是糟心。

        其分层原则则是根据水平、垂直维度进行划分。水平和垂直的划分，总的有个标准。水平划分的深度最易理解的是根据面向用户设计架构的远近，垂直的划分总根据用途交易划分，实在无法划分的，至少水平方向是那一层还是可以明确了。有了这样的结构化思维，脑海里面就对平台有个概要认知。

  下面着重讲一下网关、业务服务、能力服务，这三个就是应用架构的主体。无论是业务平台，基本应该都可以这么划分。

网关

        现在基本都是前后端分离的服务，网关的重要性在应用分发和鉴权。针对自身用户使用的云平台和第三方系统对接的用户，采用不同的入口。

        开放接口网关，一般是基于oauth2.0协议，对接是第三方的应用系统，第三方系统访问的授权是基于应用，并不是针对用户，这个跟内部网关是区别的。为什么会有开放接口网关微服务和开放鉴权服务两个呢，因为spring-cloud-starter-oauth2已经讲Oauth2.0封装好了，它自身已经比较完备了，可操作空间不大。而接口鉴权微服务，是用来设计第三方系统是否有该接口的权限，接口的访问频率、访问次数控制，这个对接数据库，有通用化设计也有其个性化设计，因此这个可以单独拿出来作为一个独立的微服务。

业务服务

        业务服务是跟其公司的业务相关，电商平台跟我们岁月会计云是不一样。我们是财税类产品，主要业务是财务、供应链、档案、运营四部分。

        运营的作用是为平台中各子产品提供可配置的权限和套餐组合，另外记录用户的订单信息。

        而财务、供应商、档案这三条子产品线微服务划分，是根据其系统中功能的复杂程度设计。从上午可以看出财务系统比较复杂。

能力服务

        写ppt的时候总喜欢说能力支撑，能力服务层就是给上面业务服务提供支付、扫码登录、即时通讯、统计以及对接第三方系统的能力。

        IM微服务，之所以设计这个微服务是因为前端websocket通讯，总不能对接一个微服务就建立一个地址建立连接，因此设计一个统一的服务，如此websocket通讯就有了极高的扩展性。

        支付微服务，为什么有这个呢？三方支付、四方支付其核心是清算系统，而支付微服务不同的是为各应用服务提供统一的支付渠道调用，当时是仿照ping++设计的。因为微信和支付宝支付接口参数是不一样的，而通联支付等也是不一样的。之所以对接不同的支付渠道，无非是因为税率原因。提供标准的支付接口给到用到支付的应用产品，调SDK即可，开发就变得很简单了。

        微信相关微服务，这个是历史原因，微信的生态是渐进变化，之前只有微信公众号，后来有了微信小程序，再就有了企业微信私域。因此它的研究是伴随微信的发展，于是该服务就独立演进保留了下来。

        统计微服务现在设计的不是很好，后面有时间再改，但是一个小公司总不能非要用clickhouse来统计吧。有时间再研究。