#
案例
项目里有个LEADER， 我跟这个LEARDER 做了1年了，合作还算愉快。
----------------------------------
两边都不得罪，其实就是得罪两边。
--------------------------------
后来最近半年新来了个PM。这时有个新项目，LEADER建议在现有的项目上改，新PM打算重新设计。两人各执己见，一时无法决定。而我是这个新项目的重要CODER，自然我成了拉拢的对象。很难抉择该怎么站队。
LEADER算地头蛇，PM则是新官上任三把火。我是个新来的程序员，如何在这场权利的争夺中站对啊？怕误伤，误杀啊。
坚定的支持leader啊 搞走PM leader升PM
你升leader
慢慢来吧，小伙，与人斗其乐无穷
-------------------------------
这种方法一般程序员也干不了。
两不靠需要很好的掌握平衡，否则后患不少，不过反正你新来，可以走，也可以调。
选边的话，需要你花心思了，琢磨人的心思，还要设局。个人觉得对你难度太高。选边的另外一种办法是选定一个，无原则支持，但是你是新来的，有这么深厚的默契吗？
还有一个角度：你有没有能力去协调双方？
---------------------------------
改善非功能需求的最佳实践冗余负载均衡
方式有网络切换、集群管理、基于DNS配置的切换
算法有随机算法、选择响应时间最快的算法、选择负载最轻的算法、重型算法
失败转移
集群
将服务器组成一组，来统一进行管理，检测软、硬件的失败，处理系统的失败转移，自动因失败事件而重启
集群配置方式
两节点集群、集群对、Ring、N+1、N to N
改善性能性能有两个关键点：
处理时间，从计算、数据调度、缓存和网络传输
阻塞时间，来源于资源竞争和另一流程的依赖
处理措施使用好的算法或适用的技术
引入并行计算、限制并发请求以避免系统过度使用、TIME OUT措施
高可用可用是指随时才能访问，不能访问的原因是硬件、网络、服务器软件、和应用组件的失败；
如果一个应用组件不能提供足够快的响应时间也是指不可用了，这是指系统正常运行情况下，由于正在同时处理很多任务而导致的延时。
改善措施集群中的复制，有活跃式的复制：发给所有节点，节点都同时进行运算，但只采用其中一个作为响应；被动式的复制，只有主节点响应请求，其他节点与主节点同步。
扩展性改善扩展的原因通常是因为需求的变更。最重要的目标是改善系统开发以适应快速的变化。
可采取的方法有：定义清晰的范围、预知可能的变更（如果界面技术，隔离这一区域使其不能波及到其他地方）、使用高质量的对象模型（使用MVC模式来解耦界面组件和业务组件）
伸缩性的改善垂直伸缩：增加处理器或内存等，对系统是透明的；
水平伸缩：增加服务器，必须避免对服务器物理位置的依赖。
架构中的层
两层结构的系统指C/S架构的程序。通常指包含了展示和业务逻辑的客户端和服务器上的数据库。展示和业务逻辑紧密结合。
优点安全是一点，由于这些系统是位于防火墙后面，员工不能使用不安全的的PC。性能通常比较好，如果公司不使用比较老的很少内存的电脑的话。
缺点可用性是一个缺点，因为如果一个元件不能工作的时候，整个系统就变得不可用。
伸缩性是一个问题，由于维一能够增加的元件是数据库。
为了能增加新功能，你很明显会影响到其他元件，扩展性不行。
可管理性也是一个问题，监控所有正在运行客户端的PC是不可能的。
可维护性和可扩展性一样。
可靠性不是一个优点或缺点，由于请求增加时，所有的这些请求来到数据库，所有的数据库能处理增长的交易吞吐量。
三或多层架构的系统三层架构由WEB，业务逻辑和资源层组成。多层架构的系统有WEB，业务逻辑，整合和资源层。在非功能需求方面，三层和多层架构的系统拥有相同的优点和缺点。
优点当将展示层逻辑从PC客户端移到服务器端，而能被集群时，伸缩性被改善了。
由于集群层能够提供失败转移机制，可用性也有所改善。
由于功能被分解到不同的层中，扩展性也有所改善。你可以更改表现层又能使得对业务逻辑影响最小。
对于可维护性也是这样。
由于各层是部署在服务器上，使得监控各个元件变得更容易，这样可管理性也提高了。
分层对于安全性可以做得更多，但必须小心对性能造成影响。
性能可能是优点或缺点。主要还是优点，当分割线程到各服务器上时，如果你要在服务器间传送大数据时，这时可能会变成缺点了。
缺点多层系统原生是比较复杂，多层架构的系统其实是没有所谓的缺点。虽然这样说，并不会由于你有了多层设计，你就有了很好的架构。必须记得不要过度使用层数。
小结
架构是一系列的使得系统能够由一组具有自己的上下文的简单的子系统组成的结构规则。
性能是指系统的响应时间，如必须在3秒内响应。
伸缩性是指当访问量增加时可以增加冗余的组件，部署到增加的服务器上时，原系统无须作更改。C/S结构的系统，由于系统安装在客户端，就不能作这种伸缩。
扩展性，是指增加或修改功能时对现有的系统不会构成影响。如MODEL1的情形，系统没有分层，所有代码混在一起，更改时会互相影响。
可靠性，是指访问量增加的时候，事务有保证。通常数据库对增加的请求，事务的保证方面已经是有所处理了。
可用性，是指系统中的某个元件失败时，系统还能访问。如果是C/S架构的系统，无法分层，某个元件出现问题时，系统就不可用了。
可维护性，是指调整现有的系统流程，不会影响到其他元件。
可管理性，是指能监控系统伸缩能力，可靠性，可用性，性能和安全。
安全性，是指系统能够阻挡非法访问。
| 云计算技术简介 |
云计算技术概述，大数据时代来临，Google云计算技术，Amazon云计算技术，微软云计算技术等。 |
| 初始Hadoop |
Hadoop的起源、解决的问题、
以及它的特点、应用场景和发展趋势，企业应用情况，为什么使用，及其生态系统介绍。 |
Hadoop
单节点伪分布式安装 |
Hadoop
1.0 版本 安装环境搭建 |
Hadoop
架构 |
Hadoop
整体架构设计及重要的概念 |
Hadoop
HDFS 体系结构 |
1：HDFS
架构设计目标，设计思想，
2：特点，基本概念，容错性。
3：HDFS
界面介绍
4：HDFS
服务 |
Hadoop
HDFS 命令行 |
Hadoop
HDFS Shell 基本操作 |
HDFS
Java API 使用 |
1：基于Eclipse开发环境搭建
2：Java
API示范 ：比如建立文件，删除，移动复制等 |
Hadoop
MapReduce 架构 原理 |
1：MapReduce 架构详解
2：MapReduce
流程
3：MapReduce
特点
4：MapReduce
容错性
5：MapReduce
服务 |
Hadoop
MapReduce api |
1：Mapper
2：Reducer
3：Driver |
Hadoop
MapReduce 编程实践 wordcount |
1：WordCount
程序编写，演示
2：运行MR
Job 示例 |
高级MR
编程 |
1：RecordReader
2：Partitioner
3：Combiner |
Hadoop
MapReduce IO |
1：数据完整性校验
2：压缩，包括：LZO、GZIP、Snappy
3：序列化
4：基于文件的数据结构，包括：SequenceFile、MapFile |
| 调优 |
调优经验分享 |
课程中的HBase部分：
掌握HBase基本原理，应用场景，掌握基本的编程技巧
| 章节课程 |
内容描述 |
| 初始HBase |
1：NoSql
数据库简介.
2：HBase
简介及与传统关系数据库的对比。
3：HBase
应用场景，企业应用情况，为什么使用。
4：HBase
特点 |
HBase
环境搭建 |
HBase
环境搭建 |
HBase
体系结构 |
1：HBase架构
2：HMaster、RegionServer、 Regoin 等概念 |
HBase
数据模型 |
1：表
2：Rowkey
3：Column
Families |
HBase
Shell 命令行 |
1：启动HBase
Shell
2：建立表
3：访问数据（添加，删除，查询）
4：练习 |
HBase
api 简单编程介绍 |
1：基于Eclipse开发环境搭建
2：基本操作（建表，查询数据，删除）
3：高级操作
（使用过滤器）
4：练习 |
HBase
row-key 设计及Scheme 设计 |
经验分享，设计原则 |
HBase
coprocessor等高级特性介绍 |
1：coprocessor特性分析，使用场景；
2：HBase
优化简单原则 |
课程中的Hive部分：
掌握Hive基本原理，应用场景，掌握基本的编程技巧
| 章节课程 |
内容描述 |
| 初始Hive |
1：Hive简介
2：为什么使用Hive
3：Hive
应用场景，企业应用情况 |
Hive
环境搭建 |
Hive
伪分布式环境搭建 |
Hive
体系结构 |
1：Hive主要的组件
2：用户接口
3：概念 |
Hive
QL |
1：Hive
类Sql
2：DDL
3：DML
4：Select
与连接查询 |
Hive
Java API |
1：搭建
Hive JDBC 开发环境
2：Hive
JDBC 开发流程 |
Hive
用户自定义函数简单介绍 |
UDF和UADF |
课程中的分布式协调系统Zookeeper部分：
掌握Zookeeper基本原理，应用场景，掌握基本的编程技巧
| 章节课程 |
内容描述 |
| 初始Zookeeper |
1：什么是ZooKeeper
2：ZooKeeper特性 |
Zookeeper
体系结构 |
1：ZooKeeper体系结构
2：ZooKeeper存储结构 |
Zookeeper
选举与锁机制 |
1：Zookeeper
选举机制
2：Zookeeper
选举算法
3：Zookeeper
锁机制 |
ZooKeeper
CRUD API |
1：Create
2：Read
3：Update
4：Delete |
| Zookeeper
应用场景 |
Zookeeper
应用场景 |
最近公司要上一个新项目。可能要整合以前的一些系统。现在考虑是用esb企业总线进行管理。初步定的是wso2。基于apache synapse。
1.一般的esb流程是什么样子的？
是不是主系统发生soap请求。esb接收并且转换成jms然后子系统监听jms。最后得到数据。
还是。jms仅仅是内部转换。soap请求在esb转成jms后。加入队列。然后再转成soap调用子系统？
2.使用jms的考虑是jms对队列的信息进行持久化。防止比如子系统突然挂掉了。消息丢失。
但是有个问题。是esb自动监听jms的队列的话。会导致直接消费了。而数据没有存在队列中。还是会出现消息丢失的问题。
这个应该怎么解决。
3.esb进行协议之间的转换。每种方式都需要些一个转换方式么？有没有什么通用的。或者是自动转换的。比如soap和jms的互相转换。不是协议切换。是内容转换。
4.如果大家有讨论esb的群。或者有高手愿意指点一下。谢谢了。
------------------------------------------------------------------
1，一般ESB的流程，
先是整理需连接的系统，需要连接的系统功能(一般管它叫服务)，确定服务的依赖关系，支持的协议(文件，WebService, RPC,...),调用的方式(同步/异步)
然后使用ESB提供的那些协议组件，一点点串起来就行。串的方式可以参考EIP (www.eaipatterns.com)
你说的两种异步方式的话都可以，
如果是同步的，也可以直接soap -> soap, 不用JMS。 一般用JMS是为了实现异步通讯
2，JMS，至少我接触的ActiveMQ， 是可以支持事务的，发生异常，可以不消费信息
3，协议转换是为了配合你那些需要整合的系统，如果都是SOAP，也就不需要转了。
消息内容转换(格式，内容)，一般ESB都提供各种工具的。
------------------------------------------------------------------
1、如果你要做同步转异步，可以在esb上做成ws转jms，然后起到一个缓冲的作用。
最后可以再同步的返回给调用方。
你也可以修改调用方为jms方式，这样就是彻底的异步了，在esb端可以jms转ws，调用业务服务方的ws。
2、esb都支持事务的，jms中如果不确认消息的话，不会从持久存储去delete掉的。
一般的esb。也可以做成是esb消费掉消息，然后存入esb自己内置的jms provider中，这样你再消费的话，也是可靠的。还可以做成补偿机制的，即esb中如何消息处理失败，把消费放回去原来的queue或是一个中间的临时queue，稍后做recover。
3、从esb的不同transport进去的数据，在esb的中介层处理时，其实消息格式都是一致的、通用的。也就是说常见的ws或jms转换在一般的esb里处理都很简单。如果稍微复杂点，也很容易扩展transformer（比如通过xslt做xml格式转换）来实现数据内容和格式的转换。
在一个开发团队中，产品经理、设计、开发、市场以及运营通力合作才能让一个产品走向成功。
而在产品从稚嫩到成熟的这个过程中，产品经理至始至终都有着自己的职责。而通过对这部分的职责的认识就有助于在产品开发过程中更好的为自己定位，让工作更有效率的完成。
在不久前有这么一个段子：
产品经理有30%的时间到处溜达，打开所有网上正在内测、封测、公测、正式发布的SNS、微博、问答、客户端产品；20%的时间在QQ、MSN、微博上扯谈、求码；30%的时间永无休止的立项、用研、交互评审、UI评审、测试、发布、运营会议；20%的时间写BRD、PRD、MRD、DEMO、运营方案。
虽然在这个段子里我们看到的是一个轻松诙谐的产品经理介绍。不过在实际工作中，一个产品经理的在整个产品的生命周期中有着需要严谨履行的职责。
一：产品概念阶段
1：在公司内外寻找产品创意。组织进行论证和充实。
2：组织所辖产品线的市场细分选择，并制定产品线初始业务/路标计划（需求规格/RoadMap）。
3：根据市场变化进行定期和不定期的计划调整工作。
4：参与产品战略和产品平台规划工作。
二：产品需求阶段
1：组织所辖产品的需求采集。
2：组织收集/分析宏观环境，技术趋势，竞争对手，内外部客户的信息。
4：组织对于产品相关的各种战略，计划，策略的审计工作。
5：研究市场动态，提交市场研究报告，选择细分市场，确定产品定位。
6：收集各个部门第产品初始业务/路标的意见。
三：产品设计阶段
1：组织完成从产品创意到产品设计，形成完整的产品业务需求。
2：组织对产品设计的测试工作。
3：提交完成的产品业务需求，协调相关资源。
4：提交产品开发任务书，获得授权，督导产品开发工作。
四：产品开发阶段
1：监督产品开发计划，产品业务需求的完成情况。
2：组织产品的市场调研工作，收集产品信息，根据需要调整产品业务需求和产品开发计划。
3：组织或者参与研发开发阶段评审。
4：协调资源对产品开发过程中的中间交付件进行测试。
5：指导产品开发过程。
五：产品测试阶段
1：组织产品的测试工作。
2：制定产品的上市计划，为产品上市做培训，文档等前期准备工作。
六：产品发布阶段
1：负责产品的市场发布工作。
2：指导并监督产品的运营和销售工作。
3：协同财务/市场部门监控产品的盈利情况，提出新的营销策略。
4：根据市场反馈，提出产品的改进意见/监督执行。
一、什么是架构
架构就是系统的结构，是一种机制。
架构就是系统的结构。你建立架构来解释将来系统的结构和这种结构如何支撑业务需求和非功能需求。你可以定义这种结构作为一种机制，系统如何用来解决一些普遍问题。这个机制有能力以统一的方式支持业务需求。例如，持久化机制必须被系统统一使用，这意味着，任何时候系统如果要做持久化，必须以同样的方式。将持久化机制定义后，你就提供了一种默认的所有设计人员必须遵循的方式。这些架构体制，如持久化、分布式、通讯、交易管理和安全就是你建立系统的基础，而且必须得建立的。
什么是建立架构呢？就是你建立的符合系统中规定的非功能需求的基础。例如，系统中说明对用户的反应时间不能超过3秒，你建立的软件基础就必须符合这个需求。这同时也意味着你已经给设计人员一个允许他们设计和编码来建立系统时而不必担心这些非功能需求。一个关于架构中比较真实的问题是：架构的建立什么时候停止，设计流程什么时候开始？对于每个系统没有最终答案。这个架构和设计的问题可以被总结起来和控制。架构定义了将会建立什么，设计了你怎样建立系统的外框。一个或少数人关注全景来控制架构的流程，其他多数人关注如何实现全景是设计所要控制的。架构师设计架构，设计团队在这个架构中用它来达成系统的全部目标。因此，如果你正在为有经验的设计人员建立架构，你就不必象为缺少经验的设计人员那样提供尽可能详尽的文档。
当你在建立架构来没跟系统的非功能需求时你通常不会有无限制的资金来购买硬件、软件和开发资源，因此你必须使系统能在有限的预算中很好的运行。例如，当你只有一台电脑来支撑内部用户时，你怎样建立可拓展的系统来满足互联网时代？没有资金来购买软件产品时，你怎样建立架构？这些就是架构师们建立系统架构时面对的问题的例子。你会面临很多困难的选择，和做很多取舍来解决这类问题。由于你作了取舍，很重要的是取舍你必须用文档说明，使得开发人员能够理解为什么要作这个取舍，这样你就不会收到来自开发人员的问题了。如果你决定使用ORACLE在系统中，你就必须用文档注明为什么要选择ORACLE而不选其他数据库。你建立架构时的取舍关注非功能需求。大多数系统没有足够的资金来满足所有的非功能性需求。作为架构师，你就必须平衡非功能需求和预算之间的矛盾。如果要做24*7的高可用光是购买硬件花掉了你全部的预算，那就是说没有多余的钱来购买应用服务器来维护非功能需求了，你就必须调整你的软件架构了。调整依赖于你正在建立架构的系统和与投资人的关系。
二、架构师角色
架构师必须具有以下特点。
架构师必须是一个全面的，成熟的，有经验的，受过教育的，学习迅速的，一个领导者，很好的沟通，和在必须时候作出困难的决定。全面的是指，架构师必须具有业务和问题领域的工作知识。他们能够通过经验和教育获取这些知识。另外架构师也必须具有广阔的技术知识。一个好的架构师能够评估所有可能的方案不管使用何种技术。
架构师要做些什么？架构师与资深开发人员有什么不同？这些都是一些常问的问题。设计师考虑一个用户按下一个按钮时将会发生什么，架构师则考虑成行千上万的用户按下一个按钮时将会发生什么。架构师要减轻和系统相关的风险。技术风险可能是未知的、未证明的或未测试的。风险来自非功能需求，有时也可能来自业务需求。不管哪种风险，都很容易地尽早地在建立架构阶段指出这个风险。
架构师必须领导开发团队保证设计师的开发人员根据这个架构一构建系统。关于取舍必须作出困难的决定，作为领导者，就是作决定的人。为了领导项目团队，架构师必须是一个好的沟通者，包括读和写。通常是通过虚拟模型和群组讨论。如果架构师不能很好的沟通，设计师和开发人员也许不能正确地构建系统。
这个适合大数据量的分布式的企业环境。
Lily以NoSQL技术为主题，是建立在云计算上的内容仓库(content repository)。
它是基于Apache的
HBase(存储)和
Solr(索引/搜索)，并提供了大型内容集合存储与检索的解决方案。
可运用在门户网站，内容管理系统，及时搜索，档案应用，文案管理，等等。
从ITEYE上看到的，郁闷的是找不到发贴人了
从 ITeye论坛最新讨论
1.Web - Application Developer
Must to have:
熟悉Java 开发，有3-4年Java Web开发经验
熟悉常用J2EE规范，JSP， Servlet，JDBC
熟悉SQL，能熟练写常用SQL script，了解常用的SQL性能优化
熟悉常用的开源框架，Spring，Spring MVC or Struts2, OR-Maping (Hibernate, iBatis, JPA)
Nice to have:
熟悉Web Service，Hessian 等常用的远程交互协议
熟悉Ajax等Web 2.0技术, JavaScript框架 （jQuery/Dojo）
熟悉常用的设计模式，能识别代码中的设计模式
熟悉Junit testNG 等单元测试框架
熟悉WAS, Tomcat, JBoss等应用服务器
熟悉SVN, CVS等代码管理工具
有使用Maven，Ant的经验
有电商经验者优先
--------------------------------------------------------
2. Web - Application Developer: e-Commerce
熟悉Java 开发, 3-4年工作经验，熟悉jquery, EXTJS，能对页面进行调试，了解各种调试工具，如：firebug，firecookies，yslow，pagespeed
对jquery plugin有一定研究，最好自己开发过插件，有自己开发js框架经验
对开源框架有深入研究，比如SSH（Spring，Struts，Hibernate等）
熟悉设计模式
熟悉FreeMarker（开发过宏者优先）, Jstl(开发过tag lib者优先）等页面展示技术
熟悉UML，有一定的业务建模和数据建模经验。
熟悉面向对象的开发。
熟悉html，CSS。
熟悉主流应用服务器和数据库。
有大型互联网前端开发经验优先
-------------------------------------------------------------
3.Web - Sr. IT specialist - Andriod
五年以上开发经验
精通Android Framework, 3年以上Android开发和Android系统定制经验
精通三大组件（Activity/Service/Broadcast Receiver）及其应用，理解常用组件API及各项特性
精通Android UI体系并能熟练完成各个分辨率下的排版及动画
了解Android底层, 能独立解决各类机型和ROM的适配
熟练掌握Java基础开发
对常用协议及服务器端开发有所了解更佳
熟悉对多媒体和流媒体的处理
有交互式用户体验经验
有互联网或电子商务终端产品经验优先
--------------------------------------------------------------
4.Application Architect - eCommerce
熟悉java开发，7年以上java开发经验，5年以上java web开发经验
至少2年电子商务行业相关开发经验
2-3年WCS 经验 或 精通 FileNet
乐于研究技术，对新技术有较强的敏感，了电子商务行业最新技术，框架，工具
精通UML建模，有较强的撰写架构设计文档能力，能熟练使用设计模式进行架构设计
熟悉常用的开源框架，Spring，Spring MVC, Struts2 , Ibatis
熟悉Websphere application server，jboss， tomcat等应用服务器的使用和配置
有带团队的经验，有一定的组织领导能力
-------------------------------------------------------------------------
5.Application Developer - QT/C++
五年以上开发经验
精通C++，三年以上C++开发经验
精通Windows底层协议和Windows API（主要是Windows XP和Windows 7）
熟练掌握QT开发工具，具备两年以上经验，熟悉Linux
熟练掌握数据结构和常用算法
具备较强的系统分析能力
具备跨平台系统级开发经验者优先（Windows/Linux/Mac/Android）
有互联网或电子商务终端产品经验优先
-------------------------------------------------------------------------
6. Technical Team Leader - QT/C++
8年以上开发经验
精通C++，三年以上C++开发经验
精通Windows底层协议和Windows API（主要是Windows XP和Windows 7）
熟练掌握QT开发工具，具备两年以上经验，熟悉Linux
熟练掌握数据结构和常用算法
----------------------------------------------------------------------------
7.Application Developer - Power Builder
5年以上工作经验，包括3年以上的PowerBuilder开发经验
熟悉Java开发，熟悉POS业务者优先
有零售行业经验者优先
------------------------------------------------------------------------------
8.Technical Team Leader - Power Builder
8年以上工作经验，包括5年以上的PowerBuilder开发经验
精通J2EE开发，熟悉POS业务
必须具备3年以上零售行业经验
--------------------------------------END--------------------------------------
以上职位IBM目前正在热招，请有意者与我联系。
作者: 无聊人士
基于公开密钥的加密过程 比如有两个用户Alice和Bob，Alice想把一段明文通过双钥加密的技术发送给Bob，Bob有一对公钥和私钥，那么加密解密的过程如下：
Bob将他的公开密钥传送给Alice。
Alice用Bob的公开密钥加密她的消息，然后传送给Bob。
Bob用他的私人密钥解密Alice的消息。
Alice使用Bob的公钥进行加密，Bob用自己的私钥进行解密。
基于公开密钥的认证过程 身份认证和加密就不同了，主要用户鉴别用户的真伪。这里我们只要能够鉴别一个用户的私钥是正确的，就可以鉴别这个用户的真伪。
还是Alice和Bob这两个用户，Alice想让Bob知道自己是真实的Alice，而不是假冒的，因此Alice只要使用公钥密码学对文件签名发送给Bob，Bob使用Alice的公钥对文件进行解密，如果可以解密成功，则证明Alice的私钥是正确的，因而就完成了对Alice的身份鉴别。整个身份认证的过程如下：
Alice用她的私人密钥对文件加密，从而对文件签名。
Alice将签名的文件传送给Bob。
Bob用Alice的公钥解密文件，从而验证签名。
Alice使用自己的私钥加密，Bob用Alice的公钥进行解密。
根证书 根证书是CA认证中心给自己颁发的证书,是信任链的起始点。安装根证书意味着对这个CA认证中心的信任。
总结 根据非对称密码学的原理，每个证书持有人都有一对公钥和私钥，这两把密钥可以互为加解密。公钥是公开的，不需要保密，而私钥是由证书持人自己持有，并且必 须妥善保管和注意保密。
数字证书则是由证书认证机构（CA）对证书申请者真实身份验证之后，用CA的根证书对申请人的一些基本信息以及申请人的公钥进行签名（相当于加盖发证书机 构的公章）后形成的一个数字文件。CA完成签发证书后，会将证书发布在CA的证书库（目录服务器）中，任何人都可以查询和下载，因此数字证书和公钥一样是 公开的。
可以这样说，数字证书就是经过CA认证过的公钥，而私钥一般情况都是由证书持有者在自己本地生成的，由证书持有者自己负责保管。具体使用时，签名操作是发 送方用私钥进行签名，接受方用发送方证书来验证签名；加密操作则是用接受方的证书进行加密，接受方用自己的私钥进行解密。