康威定律
1、Communication dictates design（组织沟通方式会通过系统设计表达出来）
2、There is never enough time to do something right, but there is always enough time to do it over（时间再多一件事情也不可能做的完美，但总有时间做完一件事情）
3、There is a homomorphism from the linear graph of a system to the linear graph of its design organization（线性系统和线性组织架构间有潜在的异质同态特性）
4、The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems（大的系统组织总是比小系统更倾向于分解）
康威定律如何解释微服务的合理性
人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来达成对沟通效率的管理
组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计
如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更合理高效
复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的
具体的实践建议是
我们要用一切手段提升沟通效率，比如slack，github，wiki。能2个人讲清楚的事情，就不要拉更多人，每个人每个系统都有明确的分工，出了问题知道马上找谁，避免踢皮球的问题。
通过MVP的方式来设计系统，通过不断的迭代来验证优化，系统应该是弹性设计的。
你想要什么样的系统设计，就架构什么样的团队，能扁平化就扁平化。最好按业务来划分团队，这样能让团队自然的自治内聚，明确的业务边界会减少和外部的沟通成本，每个小团队都对自己的模块的整个生命周期负责，没有边界不清，没有无效的扯皮，inter-operate, not integrate。
做小而美的团队，人多会带来沟通的成本，让效率下降。亚马逊的Bezos有个逗趣的比喻，如果2个披萨不够一个团队吃的，那么这个团队就太大了。事实上一般一个互联网公司小产品的团队差不多就是7，8人左右。
小团队微服务到底拆分多少合适呢？
《How Do Committees Invent?》文中提到任务的拆解可以嵌套进行，意思是先按照大力度拆，拆分出的部分继续按照更细的粒度拆分，直到不需要拆分为止。
总之，只要说得清楚，运维能力又能跟上，一般就是合理的！
CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
Oracle IAS应用服务器
Oracle9iAS能支持您所有的互联网应用需求一无论是网站、门户，还是互联网应用。它提供了一个部署平台，支持许多不同的开发方法和符合最新行业标准的技术，还支持Java、Servlets、JSP、EJB、XML等编程语言。
Oracle9iAS与Oracle数据库紧密集成，提供了独一无二的功能，让数据库开发人员快速转变为高效的网络开发人员。通过PL/SQL Server pages(PSPs)、Oracle JavaServer Pages、Business Components for Java 或者 Oracle9iAS Forms Services, 开发人员能够利用他们的PL/SQL知识快速构建动态数据库应用。
Oracle Internet Developer Suite (iDS)提供了包括JDeveloper 和Forms Developer在内的众多开发工具，为了开发部署于Oracle9i AS的应用，已对这些开发工具做了优化
Ias技术术语
分布式部署、支持旁路认证、虚拟身份锁定、上网轨迹关联、下发策略报警、实时监控、统计报表输出。