基本思想: 拆
面向流程拆分，面向服务拆分，面向功能拆分
面向流程拆分：分层架构
展示层: 负责页面设计
业务层: 负责业务逻辑
数据层: 负责数据访问
存储层: 负责数据存储
面向服务拆分: SOA, 微服务
注册服务，登录服务，信息管理服务，安全设置服务
面向功能拆分: 微内核架构
手机号注册，手机号登录，基本信息管理，修改密码，身份证注册，身份证登录，课程信息管理。。。。。。
分层架构
C/S, B/S, MVC
例如应用程序一般的分层: 从上到下
1层: 应用程序 （主界面，联系人）
2层：应用程序架构（活动管理器，窗口管理器）
3层：库 比如 SQLite
4层：linux 内核 （实际上在这之上还应该有 shell）
无论采用何种分层维度，分层架构设计最核心的一点就是需要保证各层之间的差异足够清晰， 边界足够明显，让人能够看懂。
SOA架构 (很像我们需要的)
SOA: service Oriented Architecture. 面向服务架构。
主要的核心思想就是将那些 cross function 独立出来做成服务. 而不是每个app 都有相同的 function 而重复造轮子.
微服务
为何有了 SOA 还要提微服务？
微服务是 SOA 的实现方式, 微服务是更细粒度的SOA. 都是通过服务拆分来解决可扩展问题。
微服务的“坑”
服务拆分过细，过分强调"small"
微服务基础设施不健全，忽略了“automated”, 没有自动化的支持，例如不能自动提交，部署
微服务越来越多，导致它并不“lightweight”，规模大了，实际上就不适合微服务了。微服务的粒度最好是3个人负责一个微服务的开发.
automated 的微服务，微服务基础设施
接口框架: HTTP / RPC, 并且数据格式用 JSON.
API网关: 微服务内部之间是互通的，相互之间都是点对点的，但是外部系统想调用服务，外部系统不需要知道内部的微服务职责划分与边界，它只关注这个系统整体的服务的能力。另外，外部系统访问还涉及到安全问题。所以需要 API网关作为外部系统访问的统一接口。
服务发现 与 服务路由 实际上都是在自动化范畴里的。（可以先不考虑）
标签：SOA,服务,04,扩展,分层,面向,拆分,架构 来源： https://www.cnblogs.com/moveofgod/p/12258402.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。