2019独角兽企业重金招聘Python工程师标准>>>
目标：
企业的创新能力，快速迭代能力，资源的重复利用；避免内耗；资源分配不均，资源分配不合理，项目资源不足；
实现方式：
1. 小团队做战
2. 强大的后台资源供调度。
3. 流程标准化
4.
作者：居士慧福
链接：https://zhuanlan.zhihu.com/p/30340662
来源：知乎
著作权归作者所有，转载请联系作者获得授权。
3、回顾一下，目前很多企业的信息系统建设采用“烟囱式”建设方式，有三大弊端：
1）重复功能建设和维护带来的重复投资。
2）打通“烟囱式”系统间交互的集成和协作成本高昂。而且很多企业仅仅是实现了多个系统间的接口集成，完全没有做到SOA架构的核心价值--服务重用。
3）不利于业务的沉淀和持续发展。系统上线后就进入运维相对稳定阶段，当新的业务需求出现后，服务提供者团队可能存在两种情况：第一种情况是配合不好，可能直接告诉你“我们目前仅能提供这样的服务”，第二种情况是配合态度不错，但由于前期设计的通用性和前瞻性不够，导致改造工作量比较大，这个时候很可能会放弃改造，其结果跟第一种情况完全一样。完全无法通过服务重用对业务进行持续沉淀和发展。
前两者是基于成本和效率的角度，第三个则是基于发展的角度，因此第三个对企业的伤害最大。
4、再回顾一下，目前很多企业的信息中心的组织职能往往是业务支持，其核心原因是IT部门的人员不懂业务，无法对业务的下一步发展有着自己的理解和看法。而IT人员不懂业务的根本原因是因为传统上采用项目制的系统建设模式。项目制的弊端是：
A）从员工层面，员工主要是进行项目管理，对业务的参与及沉淀有限，员工能力提升与工作时间的长短并不是呈线性增长的，无法在某一专业领域得到知识和经验的沉淀，从而随着时间的流逝，越来越多的人会慢慢失去最初的工作积极性和创造性；
B）从系统层面，项目制导致当新需求提出时，可能项目组已经解散或者KPI考核已经结束，员工的主观积极性不够，如果当初通用性和扩展性设计得不够好，或者系统稳定的需要，新需求的支撑往往有心无力，从而导致事实上的稳定。
5、企业中台：重点关注业务中台的这几个点，其他的请亲自阅读原书--服务是最不需要稳定的，服务需要不断的业务滋养；共享服务体系是培育业务创新的土壤，能够赋予业务快速创新和试错能力；改变组织阵型会带来组织效能的提升；共享服务中心的划分原则；业务中台与前端应用协作；业务中台绩效考核。
A）服务是最不需要稳定的，服务需要不断的业务滋养。一个固步自封的服务，迟早逼着比它更好的替代服务出现，届时就是这个服务离开历史舞台的时刻了。服务只有在业务滋养中才逐渐成为企业宝贵的IT资产，这种业务滋养正是来自新的业务不断进行服务的接入。
B）传统上流水线的弊端是对于不同角色人员的技能持续提升是会出现发展瓶颈的，做了3年的开发人员可能跟做了5年的开发人员可能在开发能力上没有太大的区别，根本原因是这两年的差别仅仅是用自己熟练的技能多生产出几个不同的系统。
C）针对这种情况，阿里巴巴从组织形态上进行了调整，如下图。这样，小团队的成员有足够的时间和机会对该服务相关的业务领域进行更深入的理解，从而为团队培养出既懂技术，也懂业务的复合型人才创建良好的土壤。
D）共享服务中心的划分原则：高内聚、低耦合；数据完整性原则（是第一个原则穿透到数据层面的体现）；业务可运营性原则；渐进性的建设原则。
E）业务中台的平台稳定性：限流和降级、流量调度、业务开关、容量压测及评估规划、全链路压测、业务一致性。
F）业务中台与前端应用协作
业务中台对前端核心业务的紧密沟通机制，比如定期参与前端的业务周会建立分歧升级机制，解决有分歧的情况岗位轮转推动真正换位思考业务持续沉淀及共建模式G）业务中台绩效考核
服务稳定是重中之重业务创新推动业务发展服务接入量是衡量服务价值的重要考核客户满意度促动服务的提升6、关于SOA：SOA是一种理念，它的主要特性--面向服务的分布式计算，服务间松散耦合，支持服务的封装，服务注册和自动发现，以服务契约方式定义服务交互方式。但是，SOA并没有定义出具体的实现方式，目前有两套SOA理念的实现方式：中心化和去中心化，这两套架构并没有优劣之分，还是要针对企业的根本诉求。
A）ESB模式中心化服务架构的根本诉求：实现异构系统之间的互联。
B）去中心化分布式服务架构解决的问题：首要解决的问题是系统扩展性的问题。下面这张图是阿里巴巴分布式服务框架HSF：
地址服务器：提供部署环境中配置服务器和Diamond服务器列表信息。
配置服务器：服务列表信息，包括服务名称、接口、权重等。
Diamond服务器：类似Zookeeper，在HSF框架中主要保存服务管控规则。
服务提供者：一个服务对应一个tomcat、一个虚拟机。
7、关于微服务：微服务架构的典型特征包括--分布式服务组成的系统，按照业务而不是技术来划分组织，做有生命的产品而不是项目，智能化服务端点与傻瓜式服务编排，自动化运维，系统容错，服务快速演化。
A）从本质上说，微服务是SOA的一种演变后的形态，与SOA的方法和原则没有本质上的差别。
B）随着容器化技术Docker的盛行，一些文章将微服务和Docker关联到一起，甚至划上等号，这就有点误导的嫌疑。从技术角度，Docker完全有能力而且适合微服务体系中给服务提供实际的运行容器以及进行部署运维的平台，但Docker本身提供的核心能力仅仅是计算资源层面，对于微服务架构所需的应用服务层面还存在不小的空缺，而这些空缺不是单单Docker平台能解决的问题。
服务管控：在分布式服务体系下，服务链路跟踪、链路分析、实时业务指标的监控等问题，也都是实现微服务架构时一定会面临的问题。分布式事务问题。自动化运维和平台稳定性。C）微服务不是免费的午餐，带来好处的同时，也带来一系列问题，需要一个专业的团队和平台来保障微服务架构的成功落地。
D）阿里巴巴共享服务体系的实践，称得上是微服务架构在大型互联网公司中的最佳实践
转载于:https://my.oschina.net/zhaolin/blog/2987501