可扩展架构的基本思想是：拆
不同的拆分方式，本质上决定了系统的可扩展性。常见的拆分思路有三种：
1）面向流程拆分：分层架构
分层架构的本质：固定的内核，移动的数据。
扩展时大部分情况只需要修改其一层，少部分情况可能修改关联的两层，不会出现所有层都同时要修改。
以简单的学生信息管理系统为例：展示层–>业务层–>数据层–>存储层
2）面向服务拆分：SOA、微服务
服务是一组相似功能的集合。
对于某个服务扩展，或者要增加新的服务时，只需要扩展相关服务即可。
以简单的学生信息管理系统为例：将系统拆分为注册、登录、信息管理、安全设置等服务
3）面向功能拆分:微内核架构
以简单的学生信息管理系统为例：每个服务都可以拆分为更多细粒度的功能
当然，这几个系统架构并不是非彼既此的，而是可以组合使用。
分层架构
分层架构也叫N层架构，通常情况下，N至少是两层。
分层架构的本质在于隔离关注点（separation of concerns），即每个层中的组件只会处理本层的逻辑，核心就是需要保证各层之间的差异足够清晰，边界足够明显，让人看到架构图后就能看懂整个架构。
根据不同的划分维度和对象，可以得到多种不同的分层架构：
1）C/S、B/S架构
2）MVC、MVP架构
3）逻辑分层架构
逻辑分层架构中的层是自顶向下依赖的，如andoid操作系统的架构
SOA架构
SOA(Service Oriented Architecture)提出来三个关键概念：
1）服务
所有业务功能都是一项服务，服务意味着要对外提供开发的能力，当其他系统需要使用这项功能时，无须定制化开发。
2）ESB(Enterprise Service Bus)
ESB是将企业中各个不同的服务连接到一起。SOA使用ESB来屏蔽异构系统对外提供各种不同的接口方式，以此来达到服务间高效的互联互通。
3）松耦合
目的是减少各个服务间的依赖和相互影响。
SOA架构是集成的思想，是解决服务孤岛打通链条，是无奈之举。ESB集中化的管理带来了性能不佳、厚重等问题，也无法快速扩展。所以不适合互联网的业务特点。
微服务架构
微服务是一种和SOA相似但本质上不同的架构理念。两者都关注于“服务”，都是通过服务的拆分来解决可扩展性问题。本质上不同在于几个核心理念的差异：是否有ESB、服务的粒度、架构设计的目标（small、lightweight、automated）等。
微服务架构其实相当复杂，可以分成几个阶段理解：
1）第一阶段，微服务架构就是去掉了ESB的SOA架构，只不过是通信的方式和结构变了。对于初级的使用者而言，这样理解没有太大问题。
2）第二阶段，没有了ESB，原本很多由ESB组件做的事儿，转到服务的提供者和调用者这里了。他们需要考虑服务的拆分粒。大体仍然算是SOA架构。
3）第三阶段，随着服务的数量大幅增加，服务的管理越来越困难，此时DevOps出现了。这个阶段的微服务架构，已经是跟SOA架构完全不同的东西了。
要逐步演进和迭代，不要过于激进，更不要拆分过细，拆分的粒度，要与团队的架构相互匹配。（康威定律）
SOA和微服务的区别：
1）服务粒度
2）服务通讯
微服务推荐使用统一的协议和格式。
3）服务交付
SOA更多的是考虑兼容已有的系统；微服务的架构理念要求“快速交付”，相应的要求自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。
4）应用场景
SOA更适合庞大、复杂、异构的企业级系统，这也是SOA诞生的背景。
微服务更适合快速、轻量级、基于Web的物联网系统。
微服务的陷阱及问题
1）服务划分过细，服务间关系复杂
2）服务数量太多，团队效率急剧下降
3）调用链太长，性能下降
4）调用链太长，问题定位困难
5）没有自动化支撑，无法快速交付
6）没有服务治理，数量多了之后管理混乱
微服务架构实践
1.服务粒度
三个火枪手原则。亚马逊CEO Jeff Bezos有个一个经验法则：如果两个披萨对于一个团队来说不够，那么这个团队就太大了。
2.拆分方法
1）基于业务逻辑拆分
2）基于可扩展拆分：区分稳定服务、可变服务
3）基于可靠性拆分
好处：避免非核心业务故障影响核心业务；核心服务高可用方案可以更简单；能够降低高可用成本
4）基于性能拆分
将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务。
以上方案可自由排列组合。
3.基础设施
1）服务发现、服务路由、服务容错：这是最基本的微服务基础设施
2）接口框架、API网关：主要是为了提升开发效率
3）自动化部署、自动化测试、配置中心：主要为了提升测试和运维效率
4）服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率
以上3、4会随着微服务节点数量增加而越来越重要，当节点较少时，可以通过人工支撑，虽然效率不高，但也基本能够顶得住。
微内核架构
微内核架构也被称为插件化架构，是一种面向功能进行拆分的可扩展性架构。
微内核架构包含两类组件：核心系统和插件模块。核心模块负责和具体业务功能无关的通用功能，如模块加载、模块间通信等；插件模块负责实现具体的业务逻辑。
微内核的核心系统设计的关键技术有：插件管理、插件链接和插件通信。
常见架构有：OSGI、规则引擎架构、Atlas容器化框架等。
android架构模式参考：
1.Atlas：手淘Native容器化框架和思考
2.微信 Android 客户端架构演进之路
康威定律
微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了，而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证，这就是康威定律（Conway’s Law）。
在康威的这篇文章中，最有名的一句话就是：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)
中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。
Mike从他的角度归纳这篇论文中的其他一些核心观点，如下：
- 第一定律：企业沟通方式会通过系统设计表达出来——Communication dictates design
- 第二定律：再多的时间也没办法让任务完美至极，但总有时间能将它完成——There is never enough time to do something right, but there is always enough time to do it over
- 第三定律：线型系统和线型组织架构间有潜在的异质同态特性——There is a homomorphism from the linear graph of a system to the linear graph of its design organization
- 第四定律：大系统比小系统更适用于任务分解——The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems
康威第一定律
“人类是复杂的社会动物。”
《The Mythical Man-Month》 这本书里有一句令人难忘的话：在应用项目后期加大人员的投资，会更加拖慢它的速度。——Fred Brooks（1975）
沟通的问题会影响系统设计，进而影响整个系统的开发效率以及最终结果。
康威第二定律
罗马不是一天建成的，学会先解决首要问题。
敏捷开发巨头之一Erik Hollnagel 在他的书中阐述了类似的观点：
问题太复杂？那么不妨忽略不必要的细节。
没有足够的资源？放弃无用的功能。
——Erik Hollnagel（2009）
系统的复杂性、功能数量、市场竞争以及投资人的期望值都在增加，而人的智力是有上限的，没有企业能说一定能找到合适的人，对于一个极其复杂的系统，总会有考虑不周全的地方，Erik认为这个问题最好的解决办法就是：不去管它。
最佳解决方案不是消除所有问题，而是允许它们存在，在发生故障时实现自动恢复。
在由微服务组成的系统中，每个微服务都可能停止响应，这是完全正常的，只需要确保足够的冗余和备份，这就是弹性或高可用性设计。
康威第三定律
创建独立的子系统，减少沟通成本。
团队中微服务的理念应是Inter-Operate，而不是Integrate ，Inter-Operate是指定义系统边界和接口，并为整个团队提供完整的堆栈，实现完全的自制。如此就能降低系统间的依赖性，减少通信成本。
康威第四定律
前面提到，人类是复杂的社会动物，人与人之间的交流是非常复杂的，当涉及到一个系统时，人们经常选择增加人力去减少复杂性，对于企业来说，该如何处理这样的沟通问题？答案是：分而治之。
康威定律与微服务
再来看一下康威定律是如何在半个世纪前就奠定了微服务理论基础的。
- 人与人之间的交流很复杂，每个人的精力是有限的，因此当问题很复杂，需要协调地去解决时，需要将组织划分进而提高沟通效率。
- 团队成员工作的系统设计依赖于成员之间的沟通，管理人员可以调整划分模式，实现团队之间的不同沟通方式，这也会影响系统的设计。
- 如果子系统有清晰的外部通信便捷，那么就可以有效地降低通信成本，响应地设计将更加适合和有效。
- 需要不断优化一个复杂的系统，并容错性和故障恢复率的帮助下进行优化，不要期望大而全面的设计或架构，因为它们的开发以迭代的方式发生。
以下是一些具体的实践建议：
- 利用一切手段提高通信效率，如Slack、Github和Wiki，且只与相关人员进行沟通，每个人和每个系统必须有明确的职责，在遇到问题时，知道该找谁去解决。
- 在MVP模式下设计一套系统，以迭代的方式优化及验证，并确保系统的弹性。
- 采用与系统设计相一致的团队，以扁平化和以业务为基准的方式去简化团队，每个小团队之间必须有对应负责的模块，避免模糊的界限，以免在发生问题时互相推卸责任。
- 要做小而美的团队，人员数量的增加会降低效率以及加大成本，亚马逊CEO Jeff Bezos有个一个经验法则：如果两个披萨对于一个团队来说不够，那么这个团队就太大了。一般来说，一家互联网公司的产品团队由7到8个人组成（包括前端和后端测试、交互和用户体验师，一些人可能身兼数职）。
在查看以下微服务标准时，我们可以很容易地看到微服务与康威定律之间的密切关系：
- 由分布式服务组成的系统
- 企业部门的业务线
- 开发优秀的产品
- Smart endpoints and dumb pipes
- DevOps
- 容错
- 快速发展